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EXECUTIVE SUMMARY 


The current project is part of a larger fault management research program 
funded by NASA-Langley. The focus of this project is on alerting pilots to 
impending events in such a way as to provide the additional time required for 
the crew to make critical decisions concerning non-normal operations. The 
project addresses pilots' need for support in diagnosis and trend monitoring of 
faults as they affect decisions that must be made within the context of the 
current flight. 

Monitoring and diagnostic modules developed under the NASA Faultfinder 
program were restructured and enhanced using as inputs data from an 
engine model and real engine fault data. The model and data represent a 
current high by-pass turbofan engine. A total of eight (8) fault scenarios were 
prepared to support knowledge base development activities on the MONITAUR 
and DRAPhyS modules of Faultfinder. An analysis of the information 
requirements for fault management was included in each scenario. A 
conceptual framework was developed for systematic evaluation of the impact of 
context variables on pilot action alternatives as a function of event/fault 
combinations. A major effort on the project involved an attempt to reduce 
spurious symptoms in the output of the monitoring module. These spurious 
symptoms have been greatly reduced but not eliminated. The rule base in 
STAGE 1 of DRAPhyS has been substantially enhanced based on fault data. 
STAGE2 of DRAPhyS has been modified to accept inputs directly from 
MONITAUR and suggestions for further enhancements to STAGE2 have been 
prepared. 
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Lesson learned include: 

1. Solution of the spurious symptom problem with MONITAUR is 
imperative before proceeding much further with enhancement of 
diagnostic capability. 

2. An adequate fault data base must be identified and accessed in order to 
support further feasibility testing of the Flight Deck Engine Advisor 
system. 

3. The impact of context variables on the appropriateness of crew action 
alternatives in the face of event/fault combinations needs to be 
systematically evaluated. 

4. The impact of current and anticipated levels of automation on fault 
management in general and on context/crew action relationships in 
particular should be determined. 

A proposal submitted for follow-on activities in developing a Flight Deck 

Engine Advisor system addresses the above recommendations. 
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FLIGHT DECK ENGINE ADVISOR 
FINAL REPORT 


1.0 INTRODUCTION 

In today's commercial airliner flight decks, a non-normal event must have 
occurred or a parameter threshold exceeded before an alert is evoked. This 
leaves the crew with little or no advanced warning when response decisions 
have to be made to events such as flame outs, thrust shortfall, or engine 
overspeed. The degree of automation now present in the subsystem interface 
on modem commercial airplanes can lead to situations where pilots are out of 
the loop until their intervention is required. This in turn can lead to a 
degradation in systems situational awareness and make the decision process 
more difficult with a higher probability of error. 

Automated monitoring and integration/fusion of engine data and airplane 
information, for the purpose of diagnosing subtle faults or anticipating engine 
abnormalities, could provide the additional time required for the crew to make 
critical decisions concerning non-normal operations. This is especially 
applicable during periods of high workload or during situations where 
vigilance is reduced (e.g., long hard flights). 

Single events (e.g., flame outs, etc) can be the result of many different faults. 
However, the action required by flight crews to maintain or guard against 
degradations in flight safety can vary as a function of both the fault and the 
context in which it occurs. This program addresses pilots' need for support in 
diagnosis or trend monitoring on faults m they affect decisions that must be 
made wi thin the context flf the current flight . Thus, aiding in diagnosis or 
trend analysis need only be taken to the level at which crew actions and/or 
decisions are affected. 

1.1 Approach 


The Engine Advisor development effort addresses issues from a pilot's 
perspective (as opposed to that of a maintenance technician). The focus is on 
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the integration and correlation of flight deck information within the 
framework and foundation of the NASA Faultfinder Program (Refs. 1,2, 3, 4) 
and is guided by the constructs of crew-centered automation(Ref. 5). This 
effort builds upon the monitoring and diagnostic aspects of the Faultfinder 
program, augmenting and restructuring where necessary to accommodate 
new technologies, and adapting the Faultfinder modules to be consistent with 
current Boeing flight deck systems, operational requirements, and overall 
flight deck philosophy. 

Figure 1 illustrates the relationship between relevant components of the 
Faultfinder concept and the contributions of Boeing and NASA-Langley on this 
project. The specific objectives which generate the inputs needed for this 
system are described in the following section. 

The overall goal of the program is to provide air crews with information which 
will support timely and accurate response decisions on extant or developing 
engine faults. 

This information will be generated by monitoring and diagnosis, correlated 
with the phase of flight, operational constraints, airplane state, and the pilot's 
overall flight objectives. Pilot expertise, flight operations manuals, flight deck 
engineers and propulsion experts are being used to address a range of 
situations and identify the information requirements. 
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tJ2 Objectives 


The multi-year goal of the program is to develop an expert system advisor 
which: 

* 

assists the crew in system diagnosis (if appropriate) and recommends 
applicable procedures in response to the situation; 

advises the crew of inconsistencies, adverse performance trends, or non- 
normal situations before the condition becomes critical; 

- monitors engine performance and displays critical information to the crew. 
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Figure 1. Flight Deck Engine Advisor Modules 



Objectives for the first year effort include: 

- Select a candidate engine with readily available, stand alone engine model 
and substantial real engine data; 

- Select and employ hardware/software tool combination(s) with maximum 
utility and transportability; 

- Develop a set of fault scenarios for use in knowledge base 
augmentation/restructuring and future testing; 

- Develop a data base of pilot information requirements to accompany fault 
scenarios; 

- Restructure and augment STAGE 1 & STAGE2, respectively, of DRAPhyS 
portion of Faultfinder. 


2.0 FLIGHT DECK ENGINE ADVISOR PROGRAM PROGRESS 

2.1 TASK 1- Program Plan Development 

A Detailed Program Plan was developed and delivered as Boeing Document 
D6-55677 on May 3, 1990. A revised version was approved by June 1, 1990 and 
work began on implementing the plan to achieve first year objectives. 

2.2 TASK 2- Definition and Scope of Effort 

The definition and scope of the current effort insofar as fault coverage is 
concerned involved four activities. These were: 

- Define a sample of faults which would represent total possible faults; 

- Determine sources and availability of fault propagation data; 

- Determine approach and format for fault data representation; 
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Conduct preliminary screening of candidate faults. 

The first step in assembling a candidate fault pool involved canvassing the 
various sources of such information. These included: 1) faults used by NASA 
in evaluating Faultfinder modules and related research (Ref. 6); 2) ASRS 
incident reports; 3) Boeing safety data on Boeing planes with advanced 
cockpits; and 4) flight test data from Boeing propulsion groups. This produced 
a substantial list of events on which to carry out the initial screening task. For 
many of the events, particularly those taken from ASRS reports, information 
on the nature of the fault was so sketchy as to make the instance of no value for 
the project. 

When faults were evaluated for availability of real engine data on which to base 
fault propagation, the candidate pool quickly shrank to those faults identified 
by Boeing propulsion groups. No other source could provide both real engine 
fault data plus matching normal simulated data generated under the same 
flight conditions. Both these types of data are required to test the monitoring 
and diagnostic modules. Thus, a much reduced but realistic candidate fault 
pool was generated. 

Initially, a quantitative approach to fault symptom representation was 
planned. However, proprietary issues, which are dealt with later in this 
report, precluded the inclusion of quantitative data as a part of the deliverable 
reports on the project. Therefore, the quantitative engine data was used as 
input to MONITAUR in module development and testing but only qualitative 
representations are included in the deliverables. 

The scoping process as defined above was carried out over several months 
rather than the originally scheduled one month period in order to include all 
possible faults for which data sources could be identified. This did not affect 
progress on the project because an iterative approach to fault scenario 
development was employed. Implementation of the iterative approach meant 
that data gathering, scenario development, and information requirements 
analysis activities could proceed in parallel without having to wait on the 
completion of any one task. 
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The Technical Monitor was kept apprised of the progress and results of 
activities in this task and had the opportunity to provide inputs regarding 
specific priorities and preferences. 

2.3 TASK 3- Hardware/Software Selection 

Several potential candidate hardware platforms were evaluated for the Flight 
Deck Engine Advisor. These included 

PC 386 

Apollo Workstation 
Symbolics 

Mclvory Workstation 
MacII 

In addition, Common LISP and NEXPERT OBJECT were considered as 
software development environments. Each component of Faultfinder 
(MONITAUR, DRAPhyS STAGE1 and STAGE2) was evaluated separately 
because they were originally developed with differing dependencies. The goal 
was to be able to link all three modules for a run-time version at project 
completion. Criteria for selection (as discussed in the Detailed Program Plan) 
included: 

Portability from NASA to Boeing 
Interface with Simulator 
Interface with Engine Model 
Real Time Performance/Response 
Cost to Implement at Boeing 
Cost to Implement at NASA 
Impact on Productivity 

Each applicable criterion will be discussed in context with the specific module 
discussed. 
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2.3.1 MONTTATTR Development 

The development of enhancements to MONITAUR was performed on a 386 PC 
using GCLISP Developer software. This development was completed using the 

3.1 version of the GCLISP Developer. A 4.0 version of the GCLISP Developer 
became available during the first quarter 1991, but this was too late to be 
utilized effectively on this contract. There are several advantages to both 
NASA and Boeing in the choice of development environment. These are 
summarized below. 

NASA advantages include the following: 

1. NASA has a GCLISP implementation hosted on a PC in their 
experimental airplane. This will facilitate the transition to inflight 
testing. 

2. A greater number of potential users will be able to utilize the PC version 
since more engineers have PCs on their desks than LISP Workstations. 
This will facilitate dissemination of the product of this study. 

3. GCLISP boasts a Steele compatibility and is upward portable to other 
Common LISP environments. 

4. No additional expense will be incurred, since NASA already owns 
GCLISP. 

5. GCLISP is available in both interpretive and compiled mode to allow 
both efficient development and better run-time performance. 

6. Porting MONITAUR from Genera Common LISP to GCLISP was 
relatively straight forward since few special Genera features have been 
used in MONITAUR. This allowed more time for fault information 
development. 
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Boeing advantages include:-, 

1. Boeing owns GCLISP so no additional costs will be incurred. 

2. GCLISP on a 386 PC is compatible with Flight Deck Research's 
MicroCab architecture so the Engine Advisor can be integrated with 
existing applications 

3. GCLISP is portable to other Common LISP environments used at 
Boeing. 

4. GCLISP is available in both interpretive and compiled mode to allow 
both efficient development and better run-time performance. 

5. Porting MONITAUR from Genera Common LISP to GCLISP was 
relatively straight forward since few special Genera features have been 
used in MONITAUR. This allowed more time for fault information 
development. 

There are some disadvantages in the selection as well. Most important among 
these is run-time performance. Even using the compiled form of GCLISP, 
execution times on a 33Mhz PC will not be in the order of real time processing 
unless time slices are taken several seconds apart. A second disadvantage of 
selecting a PC instead of an APOLLO, is the need to create an interface 
between engine model data generated on an APOLLO and the PC. If an 
APOLLO had been chosen as the development hardware, this would be an 
internal link which should be more easily developed. 


2.3.2 DRAPhvS STAGE 1 Development 

The development of enhancements to MONITAUR was performed on a 386 PC 
also using GCLISP Developer software. This development was completed 
using the 3.1 version of the GCLISP Developer. There are several advantages 
to both NASA and Boeing which are summarized below. 
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NASA advantages include the following: 

1. Since the selection is identical to that for MONITAUR, all six of the 

advantages cited in the MONITAUR evaluation apply to STAGE 1 as 

»» 

well. 

2. In addition, the compatibility between MONITAUR and STAGE1 
resulted in efficient linkage between the modules. NASA’s current 
blackboard was replaced with a PC compatible implementation. 


Boeing advantages include: 

1. Since the selection is identical to that for MONITAUR, all five of the 
advantages cited in he MONITAUR evaluation apply to STAGE 1 as well. 

2. In addition, the compatibility between MONITAUR and STAGE1 
resulted in efficient linkage between the modules. NASA's current 
blackboard was replaced with a PC compatible implementation. 

The performance disadvantages of a 386 PC platform with GCLISP are similar 
to those cited for MONITAUR. When the two modules run sequentially, the 
performance is degraded. No additional penalty exists for interfacing to 
APOLLO, since the STAGE1 module does not have engine model input. 

In addition to a PC 386 GCLISP implementation, a second option was 
investigated as an alternative for STAGE 1 processing. A demonstration of 
STAGE 1 processing using NEXPERT OBJECT was produced for alternatives 
analysis. A separate set of potential advantages was evaluated including: 

For NASA: 

1. Develop experience with a commercial shell, one that is emerging as a 
front runner in the AI community. 

2. Create a viable alternative to allow tractable rule base processing. 
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Other potential NASA-xustomers will have this shell so dissemination 
will be more efficient. 


4. Boeing has considerable experience with this development environment, 
so productivity will be increased. 

5. The knowledge bases developed in a shell are highly portable within 
NEXPERT OBJECT applications. 

For Boeing: 

1. Boeing owns NEXPERT OBJECT, so no additional software costs will be 
incurred. 

2. Other AI applications have been developed in Flight Deck Research, so 
this version will be highly compatible. 

3. Reasoning is traceable in NEXPERT OBJECT, which is important for 
Verification and Validation required for FAA certification. 

The disadvantages in NEXPERT OBJECT use is the additional cost to NASA to 

obtain NEXPERT OBJECT, and NASA's lack of familiarity with this 

development tool. 


2.3.3 DRAPhvS STAGE2 Development 


The development of enhancements to DRAPhyS STAGE2 was performed on the 
Mclvory workstation using Genera Common LISP. To allow for PC 
compatibility, Boeing investigated the feasibility of porting the product to a PC 
386 using the CLOE implementation of LISP produced by Symbolics. 

NASA advantages include the following: 

1. NASA has all hardware and software in place, therefore no additional 
cost will be incurred. 
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2. This is NASA's original development environment, so they have a broad 
experience basO. 

3. The symbolics will give better run-time performance than a PC. 

4. The PC porting under CLOE was demonstrated, and the product is 
usable by a wide variety of NASA customers. 


Boeing advantages include: 

1. The PC porting under CLOE was demonstrated, and the product is 
compatible with other Flight Deck Research applications in the 
MicroCab. 

The disadvantages of this selection include a productivity penalty for working 
on the Mclvory due to lack of familiarity for Boeing personnel. Boeing has 
incurred additional cost in securing a Mclvory for production use. Finally, the 
product is not portable from Mclvory to the PC by any means but CLOE LISP 
translation. No graphics can be translated under the current version of CLOE. 
The functional portion of STAGE2 was ported, but the interface had to be 
redeveloped for the PC version. 

2.4 TASK 4 - Fault Scenario Selection 

2.4.1 Engine Model Selection 

Criteria for the selection of an engine model for use in this project were 
developed as a part of preparation of the Detailed Program Plan. These 
criteria were applied to several engine models which have been developed by 
Boeing for implementation on flight simulators. This section of the report 
deals with a discussion of proprietary issues and their resolution plus the 
details of the engine and fault selection processes. 
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2.4. 1.1 Proprietary Issues 

At the present time, no written proprietary agreement exists between Boeing 
and NASA which adequately protects the proprietary rights of engine 
manufacturers and other parties with vested interests in the engine model 
and/or real engine data which are being used to carry out some of the tasks of 
this project should an engine model and the quantitative fault data be delivered 
to NASA. Further, no permission has been granted by parties with vested 
interest in the real data to release such data to a third party. Neither an 
engine model nor real engine data are deliverables under the contract 
Statement of Work as written. This situation does not in any way preclude 
Boeing from performing on the contract. The Technical Monitor had indicated 
early in the process of developing the Detailed Program Plan for this project 
that having an engine model and real engine data included in the Final Report 
would be a plus for their related in-house work. However, the nature of the 
engine data and the number of parties with vested interest involved are such 
that no attempt was made on the current contract to secure proprietary 
agreements or permission to release data covering engine parameters on the 
faults analyzed or any quantitative output from the engine model which 
reflects this data. Qualitative representations of engine parameter 
characteristics during fault propagation will be described in the Final Report. 
In light of the above, it is Boeing’s intention to deliver qualitative 
representations of engine parameter characteristics during fault propagation 
as a part of the Final Report, but no quantitative data will be included. 

Attempts to resolve proprietary issues on the engine model and engine data 
are continuing with respect to follow on work on the Flight Deck Engine 
Advisor program. 

2.4. 1.2 Model Selection Process 

Engine models considered in this selection process represent classes of 
engines used on Boeing airplanes. The search for a suitable engine model was 
restricted to models of engines currently implemented in Boeing flight 
simulators for three reasons. First, this restriction is required because of the 
necessity to rim the model in order to process inputs and provide outputs 
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necessary to develop and implement fault scenarios. Engine models w 
come from the engine-manufacturers are not implemented m thts sense^ T 
programming effort required to implement engine models for simulation 
beyond the resources of the present project. Hence, no consideration was given 
to using new engine models not already implemented. Second, the expertise 
needed to utilize the simulation models to provide the fault propagation 

information on the engine faults is available in house. Third, real engine a a 

are available in-house on the sample of engines considered. Any engine mo e 
which did not have the aforementioned characteristics could not be given 
serious consideration within the scope of the project. 


In order to avoid proprietary issues and constraints while documenting project 
activities or results, no identification will be made of specific engines or -Hasses 
of engines by engine manufacturer at any time during the discussion of the 
selection process or in any subsequent discussions relating to engine models. 
Engine models will henceforth be referred to as Models A, B, C, and D. Since 
each model is a different engine type and possibly a different engine 
manufacturer, separate Physical Systems Files (PSF) were created for each 
model. The only PSFs included in this report are those for which real engine 
data was obtained. In the process of developing fault scenarios, no attempt 
was made to restrict the fault selection to a specific (serial number) engine. 
The associated PSF has not been customized for a specific (serial number) 
engine, but instead is intended to represent any serial number engine of that 
type, and hence is generic for that engine type. 


The criteria used in the engine selection process are described below as a 
prelude to the description of the selection process and results. The criterion 
labels are those used in Figure 2 to facilitate interpretation of the data. 

iv/r^ml Avail ability : This refers to the availability within Boeing of an 
implemented model for a particular class of engines which can be utilized 

with little or no modification. 
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MndAl Validation 1 : Refers to-the fact that the engine model is known to run 
without problems and has been demonstrated to match the engine it 
represents. 

Protection : Proprietary protection for all parties can be assured 
and permission to transfer data to a third party can be obtained. 

Thrift Data : The extent of inflight and test data available on faults 
which might be selected for scenario development. This criterion also refers to 
the ease with which fault data from other engines can be modified to work m 
concert with the model. (This criterion and that of "availability of failure 
mode data" listed in the Detailed Program Plan are redundant.) 

ArvMirflcv- etc. : This refers to whether the accuracy, consistency, stability, and 
tolerances of the engine model are within acceptable ranges. 


Prorogation Information : This refers to the availability of expertise on fault 
propagation within and beyond the engine. High ratings were given when the 
needed expertise was available within Boeing. 

Change Information Available : This refers to the availability of information 
on changes made to the engine manufacturer's model to adapt it for 
simulation. 

r.ornmiting R.ocmirements : This refers to the type and amount of 
hardware/software support needed to run the model. Specifically, can the 
model be run on the types of hardware/software combinations being considered 
for the project, and if not, how much effort would be required to translate the 
model. A low rating indicates the required hardware platform is not readily 
available to the project and/or a large effort would be required to translate the 
model to a more accessible platform. 


1 This criterion label has been used in place of "Simulator Ready which appeared m 
Detailed Program Plan because it better reflects the basis for judgements on this dimension. 
Simulator Ready was deemed to overlap too greatly with "Model Availability as defin 

above. 
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Propulsion experts thoroughly familiar with the characteristics of all engine 
models under consideration evaluated the models in terms of the criteria 
described above. Additional factors to be mentioned later were also taken into 
consideration in making the final determination as to which model to use. 
The results of this evaluation represent a consensus of expert opinion. 


Figure 2 represents a Criteria by Engine Model matrix with the weights used 
for each criterion shown in the second column. The first three criteria were 
considered critical. Thus, a weight of 0 or 1 was used in a cutoff mode. This 
meant that if an engine model received a weight of 0 on any one of there three 
criteria it was dropped from any further consideration. The remaining 
criteria could receive weights ranging from 1 to 5. The values shown in the 
matrix cells represent a rating arrived at by consensus among the propulsion 
simulation experts. These weights were simply added up across criteria 
within engine models. The model with the highest total was chosen for use on 
the project. This choice was further substantiated by additional factors. 

As can be seen, Engine Model A has the best showing across the criteria used. 
In addition, this model is implemented as a FORTRAN callable subroutine on 
the Apollo computer using the Boeing Parallel Simulation System (PSIM). 

The PSIM is software which facilitates integration of other analysis tools or 
simulations. The other models do not use the PSIM software, and some run 
on other computers such as the Harris. The model for Engine A also runs as a 
multi-engine model. None of the other models have this capability. This 
feature will have little impact on the current project work, but will make the 
simulation of differential engine performance much easier in the future. 
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VOUU1UO 

Criteria 

Weight 

A 

B 

C 

D 

Model Availability 

0-1 

1 

1 

1 

1 

Model Validation 

0-1 

1 

0 

0 

0 1 

Proprietary Protection- 2 

0-1 





Real Engine Data 

1-5 

5 

2 

5 

4 

Accuracy, etc. 

1-5 

4 

4.5 

1 

2 

Propagation Information 

1-5 

5 

3 

2 

1 

Change Information available! 

1-5 

5 

5 

5 

5 

Computing Requirements 

1-5 


2 

2 

2 

Evaluation Score 


25 

17.5 

16 

15 


Figure 2. En gine By Criteria Evaluation Matrix 


2.4.2 Fault Selection 

A set of candidate faults has been identified for use in developing fault 
scenarios. The strong points of the subset identified to date are: a) real engine 
data exist for them, and b) the expertise for specifying fault propagation 
* sequences is available in-house. The characteristics (referred to as criteria in 

the Detailed Program Plan) which the faults should have in order to be 
maximally useful are listed below with brief descriptions. 

Credibility : Real engine fault propagation data are available on the fault. 

Within Engine : The fault propagation sequence is constrained to components 
within the engine subsystem. 

~Rp.twp.en Subsystems : The fault propagates functionally or physically to related 
or proximate subsystems. 

Flats Avail ability : Quantitative data are readily available on the fault in a 
useable format. 


2 This criterion could not be met by any of the engine model candidates so it was given no 
weight in the selection process. (See also Section 2.4. 1. 1) 
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Ptv'pqp-gt.inn Fornertise : The expertise needed to develop the fault propagation 
sequence is readily available and accessible. 

nnahle : Scenario development is doable within project resource and schedule 
constraints if the fault is selected. 

Action Ramil red : Deahng with the fault must call for action on the part of the 
crew, be it subsystem reconfiguration or control, or crew awareness for 
inflight replanning. 

Troni Inconsistency : The fault propagation occurs over considerable time so 
as to generate negative trends in engine parameters which may not break a 
threshold for some time. The fault produces inconsistencies in expected 
engine parameter values. 

Accurate Time Data : Accurate time line data are available to support fault 
propagation scenario development. The minimum requirement here is for 
accurate sequence data. 

Figure 3 represents a Characteristic by Fault Candidate matrix which 
illustrates the coverage of characteristics achieved across the fault scenario 
developed. 
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Candidate Faults 


Characteristics 



FI 

F2 

F3 

F4 

F5 

F6 

F7 

F8 

Credibility 

X s 

X 

X 

X 

X 

X 

X 

X 

Within engine 

X 


X 

X 

X 

X 

X 

X 

Between subsystems 


X 







Data availability 

X 

X 

X 

X 

X 

X 

X 

X 

Propagation expertise 

X 

X 

X 

X 

X 

X 

X 

X 

Doable 

X 

X 

X 

X 

X 

X 

X 

X 

Action required 

X 

X 

X 

X 

X 

X 

X 

X 

Trend, inconsistency 



X* 

X 

X 




Accurate time data 

X 

X 

X 

X 

X 

X 

X 

X 

Evaluation Score 

mm 

mm 

8 

8 

8 

7 

m 

mm 


Figure 3. Characteristic By Fault Candidate Matrix 

* 

Trend occurs across scenarios F3, F4, F5 


2.4.2. 1 Fault Candidates 

The following candidates were identified. As can be seen in Figure 3, when 
taken together, they contain all of the characteristics outlined above. 

FI - Malfunctioning fuel metering unit - Hung Start, ground / 

F2 - Fuel boost pump failure - Flame out / 

F3 - Ice damaged fan blades, light - Thrust Shortfall 
F4 - Ice damaged fan blades, moderate - Thrust Shortfall 
F5 - Ice damaged fan blades, heavy - Thrust Shortfall 
F6 - Foreign Object Damage (FOD): volcanic ash - Flame out 
F7 - Fuel nozzle coking - Hung Start, air ■/ 

F8 - Stability margin problem - Stall/Surge 

All of the above fault candidates were eventually developed as fault scenarios. 
The resulting scenarios are contained in Appendix A. 
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2.5 TASK 5 - Fault Scenario Development 

Early in the course of the project, it was determined that an iterative approach 
to the tasks of fault selection, scenario development, and information 
requirements identification would be most effective. Thus as real engine data 
became available on a fault, the process of developing the contents of the fault 
scenario began. As this process proceeded, the concepts and definitions 
structuring the scenario contents were fleshed out and modified. It was also 
at this tim e that it became obvious that the identification of information 
requirements needed to carry out fault detection and diagnosis was an integral 
part of fault scenario development. Therefore, the information requirements 
task was folded into scenario development and scheduling of the project tasks 
was modified to reflect the iterative nature of the overall scenario development 
process. 

Eight (8) fault scenarios were developed during the course of the study. All 
eight are included in their entirety as Appendix A of this report. 

2.5.1 Concepts and Definitions for Structuring Fault Scenarios and the 
Information Requirements Analysis 

The framework for diagnosing faults is the fault propagation sequence 
expressed in terms of system components involved and the functional and/or 
physical relationships affected. The framework for analyzing pilot 
information requirements is the event-fault-context-action alternative 
relationship which exists in a specific fault scenario. Depending on the fault 
and context variables relevant to the scenario, context may be used in two 
ways; as an aid in diagnosing faults, and in terms of its impact on action 
alternative selection. Before discussing the nature of these relationships and 
the format and content of a fault scenario, we should define the terms and 
components to be used. 
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! 

| 2.5. 1.1 Definitions 

i 

! ** 

Events - Events are those conditions which the crew must deal with. They are 
the end result of a propagation of malfunctioning components. The 
* propagation may be functional, physical, or both. Examples of events are: 

flameout; hung start; thrust shortfall; excessive vibration. 

Fa ult - The fault is the failure of an engine component which propagates 
through the engine subsystem and via this propagation results in an event. 
Examples of faults are: sensor failures, valve open/close failures, software 
logic failures or inadequacies; any mechanical, electrical, or software 
component failure; procedural failures (both maintenance and operational). 
Faults in the new engines may be mechanical, electrical, or software related, 
or may be flight crew or maintenance induced. For any given event, it is 
assumed that there can be multiple potential faults. Faults may be grouped in 
terms of the crew action alternatives; i.e., several faults may map onto a single 
crew action such as "Shut down engine for remainder of flight". It is also 
assumed that different faults will have at least slight differences (either 
temporal or sequential) in the way they propagate. Thus, if the propagation 
sequence and temporal relationships are known, the nature of the fault can be 
inferred with some degree of accuracy. The degree of accuracy in 
differentiating among faults will be a function of the number and degree of 
differences in their propagation sequences. However, if faults have essentially 
the same propagation sequence and/or the same action alternative is 
appropriate, no attempt is made to differentiate among them. These are said 
to belong to the same Fault/Action Class. 

Context - This refers to external variables which may: a) affect the way a fault 
propagates, b) affect the criticality of the fault and hence the crew action 
alternatives, or c) alter the appropriateness of crew actions. These variables 
include: phase of flight, weather, airplane systems status, engine fault 
history, engine commanded status, airline policy, FARs, pilot error, workload. 
As mentioned earlier, context variables may play two roles. Variable status 
may be used to aid the diagnostic process as well as influence the relevance of 
action alternatives. Context variable status can eliminate potential fault 
alternatives as well as make others more viable. 
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The relationship of context variables to action alternatives is an IF-TBEN 
“m P . If certain variables are operative, then a parti^ar action 
att ative is appropriate. If the variable(s) isCare) not operative, ^n there ,s 
no impact on action alternatives. In other cases, the context «AU 
have no affect on the action alternatives whether 

event the relevant context variables must be considered in the diagnosti 
p " order to produce relevant recommendations on action alternatives. 

The event-fault-context-action alternative relationship is illustratedin Figure 
4. Within this framework, context variables may be thoug o as 
may or may not be in place for a given fault. 

Alternatives - These define, at least to a category l"e »ctions 
the flight crew mighttake when confronted with an event precipitated by the 
occurrence of a particular fault within a FaultiAction class. It is assumed 
that action alternatives can be related to faults or Fault/Ariionc Ws via 
context variables. Examples of action alternatives might be. shut down engine 
for duration of flight; engine shutdown with possibility of restart later in g 
(delay unspecified at present); execute engine shutdown/restart procedures, 
reduce throttle setting but continue to operate engine; restart engine 
immediately and continue to operate normally; no action required (a pseudo 
problem). The set of potential alternative actions will vary somewhat from 

event to event. 

Svmntoms - The manifestation of the fault in system parameters againsta ^ 
tirTbase represents the symptoms of the fault. These symptoms are defined 
for the most part, in terms of engine parameters such as low rotor speed hig 
rotor speed, EGT, fuel flow (FF). However, other symptoms which are not 
sensed or are not displayed in the cockpit, or both may be relevant to the 
diagnosis of faults. An attempt will be made to identify such sysop oms or 

infer tbeir existence if possible. 

w--. „„ mw Subsystems - Faults within the engines may eventually affect 
other subsystems such as generators and hydraulic systems. These impacts 
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are noted in the fault scenario but unless they are important to the diagnosis of 
the fault, they will not'be included in the propagation sequence per se. 

Time Base - All fault candidates being analyzed have flight recorder data on 
engine parameters plotted against a time base; usually at .1 second intervals. 
This time base is taken as relative for purposes of analysis since it would differ 
in detail across engines and within engines across time or fault occurrences. 
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Figure 4. Context Variables As Filters Affecting The Fault/Action Relationship 






2.5. 1.2 Fault Scenario Sections 

Each section of the fault scenario is identified below along with a description of 
its contents. Because the fault scenario development process is iterative, the 
only sections in which the information is not subject to change are Event and 
Fault . All others can be revised during review and knowledge base 
development. Revisions in the fault scenario data base were made as long as 
the need for more and better data continued during knowledge base 
development. 

Event - contains only the name of the event. 

Fault - contains a descriptive label of the specific fault being analyzed plus any 
qualifying or modifying information. 

Potential Fault Alternatives - contains a list of other faults which could lead to 
the same event. This list was expanded as additional alternatives became 
known, but is not exhaustive. 

Relevant Context Variables/Status - contains a list of the relevant context 
variables and their particular status or "value" for the scenario. Initially, the 
relevancy of particular context variables per se or their relevance as a function 
of particular values they might assume may not be known. Thus, the listing 
for a particular fault scenario may change as knowledge base development 
progresses. Context variables identified to date are listed below along with 
examples to illustrate the status or value these variables might assume. 

Phase of Flight - Take Off; Initial Climb; Cruise; Descent; Approach; 
Landing; Go-Around. 

Weather - Clear and dry; Heavy rain; Icing; Turbulence; etc. 

FOD Potential - Several scenarios involve foreign object damage of one 
sort or another as the fault. Examples include; ice damage, volcanic 
ash damage, bird strikes, blown tire piece ingestion. 
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Ee&aal Aviatinr (FARs) • relative to constraints or options 

pilots have in specific situations. 

TCnfrinft Fault History - Information on whether the particular engine or 
engine type has a history of the fault/event occurrence and how it has 
been resolved in the past. 

Airlirift Policy - Specific actions may be dictated for specific events. 

Other context variables may or may not interact to affect prescribed 

actions. 

PVifrinfi Commanded Status. - Steady State; Acceleration; Deceleration; 
Start; Shutdown; Forward/Reverse Thrust. 

Pilot. Error - Procedural errors can be made which are in themselves 
faults in that they will produce events; e.g., improper start procedures 
can produce a hung start. However, pilot error can also exacerbate a 
fault and alter the appropriateness of particular action alternatives. For 
example, at one time certain engines would flame out when significant 
amounts of water in the form of rainfall were ingested. If the pilots 
reacted immediately, the correct action was to immediately execute the 
restart procedure. If the pilots did not react immediately or they moved 
the throttles, the only action alternative left was to shut down the engine 
for the duration of the flight. It is in this latter sense that pilot error is a 

context variable. 

Airplane, System Status - Basically, this refers to what is working on the 
airplane and what is not. Airplanes may be dispatched with certain 
components or subsystems inoperative if they are not critical to flight 
safety. An air conditioning pack might be an example. 

Workload - This refers to the aggregate demands on the flight crew in 
addition to those imposed by the event. It can be assumed that workload 
will be high during certain phases of flight (e.g., take off and initial 
climb; approach and landing) and lower at others (e.g., cruise). 
However, the correlation is not perfect. Workload can be expected to 


26 


influence the relevancy of action alternatives; particularly when it is 
high. 


Crew Action Alternatives - contains a listing of all action alternatives 
appropriate for the event under any circumstance. Options are determined in 
consultation with engineering and/or training pilots and propulsion experts. 
An objective is to have this section and that on potential fault alternatives mesh 
well in that all action alternatives are identified for the fault alternatives listed. 

Subsystems Affected - contains a list of the subsystems involved in the 
propagation sequence. Subsystems which may be affected by the event but are 
not crucial to the diagnostic process are also identified and effects noted. 

These latter subsystems will not be mentioned in the fault propagation 
sequence. 

Propagation Sequence with Rank Order Time Base - The propagation sequence 
is described in qualitative terms against a rank-ordered time base. 

Components and engine parameters are identified in the sequence in which 
they are affected by the fault. Qualitative values are given for the parameters. 
Each point on the time base when components become involved or parameter 
values change is labelled consecutively so that the order in which involvement 
and/or change occurs is apparent. 

Data Pilots Have Available - This section represents an attempt to identify and 
evaluate the sources and sequence of data acquisition pilots currently use in 
diagnosing the fault under analysis. It provides the basis for an evaluation of 
what could or should be expected of pilots when compared with the data from 
the next section. Subsections include: 

Source(s) of Data 
Explanation of Relationships 
Quality of Data 

Heuristics or Rules of Thumb Used 
Time Constraints 
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Information Required to Make D iagnosis - This represents a generic 
description of the information required to make a diagnosis in that it does not 
distinguish between what information the diagnostic module would use versus 
what pilots might use. It will, however, contain comments relevant to 
whether pilots currently have an adequate source, if any, of information 
needed to make the diagnosis. This section, the propagation sequence, and the 
context variables/status provide the data base for knowledge base development 
on a fault. Subsections include: 

Key Parameters 

Symptoms 

Interpretation 


Information Remiired for Decision Aiding - This section contains an analysis 
of the relationship between fault and action alternatives given the relevant 
context variables and their status. Subsections include: 

Nature of the Fault 
Relevant Context Variable Set 
Relationship Between Fault and Context Variables 
Diagnostic Application 
Action Recommendation Application 
Consequences of Inappropriate Alternative Actions 

Information is included in the subsections of these last three sections if and 
when it is available. A comment section may also be included when the 
analyst feels it is appropriate to provide additional information. 

2.5.2 Lessons Learned in Fault Scenario Development 

2.5.2.1 Data Availability 

With two exceptions, fault scenarios were based on flight test data. In all but 
two of the scenarios based on flight test data , the fault was induced in order to 
study the effects. This is typical of flight test data. The fact that we have data 
of such granularity on two uninduced faults is fortuitous. For the staged 
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faults such as flame out due to fuel pump failure, the fault itself is not 
necessarily low probability but very special circumstances have to obtain in 
order for it to propagate to the event which occurred. 

The faults represented are not complex (particularly in terms of the 
propagation sequence), they are never multiple, and they are certainly not 
novel. If novel faults are defined as those which have not occurred, then of 
course we will never have them in our data base. This does not mean that we 
cannot eventually devise a system which would recognize them as faults, at 
least at some level of specificity relative to actions required by the pilots. 

A number of faults were known to have occurred, but for various reasons the 
detailed engine parameter data was not available. These included: 

Flame Out in Idle Descent - electronic engine controller fault; 
Hung Start, Ground - bleed valve out of position; 

Engine Overspeed - electronic engine controller fault. 

The first would have been an excellent example of a subtle fault. The second, 
would have allowed us to compare hung starts produced by fuel management 
vs. pneumatic problems. The third is an example of unalerted automation 
failure requiring crew intervention. 

Clearly, we need an expanded fault data base for feasibility testing and for 
longer range development efforts. Some additional fault data will be available 
through further efforts to mine the flight test data files. Also needed however 
is additional operational data on both faults and normal operating engines. 

An expansion of the rationale for these needs is provided in the next subsection 
and in the section on Knowledge Base Development. An effort to identify 
sources, extent, and accessibility of a greatly expanded operational data base is 
proposed for follow on to the present study. Preliminary inquiries in this area 
indicate that the airlines probably would be the major source for such a data 
base; more so, surprisingly, than engine manufacturers. 
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2.5. 2.2 Nature of the Data 

Six of the fault scenarios developed are based on flight test data. The 
remaining two are based on data taken on a flight deck recorder. There are 
major differences between flight’ test data and operational data in terms of 
parameters recorded and granularity of the data. It is instructive to note the 
differences between these two data sources and the implications for system 
development. 

Flight tests are typically very heavily instrumented in order to: a) get the most 
data for the money, and b) obtain the clearest picture possible of the way 
various engine parameters behave during the event observed. Further, the 
data recordings are quite brief (at least in terms of data retained for storage), 
typically lasting no more than 100 seconds. Thus, the only trend data available 
is of very short duration. Operational data, on the other hand, has the 
potential of covering a much longer time span but fewer parameters are 
measured and the data is much courser. 

Parameters pertaining to internal engine pressures and temperatures are 
very useful in anticipating the onset of an event such as a surge, but the high 
fidelity sensors which provide the data during flight test are also very fragile 
and thus are unacceptable on operational engines. Another type of problem 
encountered was having data available on a parameter, but not having the 
parameter modelled in the engine model. Vibration is a case in point. Until 
engine manufacturers can provide a reliable and meaningful measure of 
vibration, this valuable diagnostic parameter will not be available. This is 
particularly frustrating in the case of the ice damage scenarios. Here a step 
increase in vibration level is the only reliable symptom indicating foreign 
object damage has occurred at low levels of damage. 

There is also the situation where engine parameters are measured and are 
among the inputs the electronic engine controller uses but the parameter 
values are not available outside the controller. These parameter values could 
be made available to a data bus if a system like the Flight Deck Engine Advisor 
were available to use them. Therefore, it is appropriate to use data from flight 
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test engine measurements to anticipate parameter values which may be 
available to the diagnostic process on future operational engines. 

There is some pressure from engine manufacturers to reduce the number of 
engine sensors. This is understandable in that sensors do fail and can 
produce false alarms which can be costly under engine warranties. However, 
a reduction in sensors would be counterproductive from a diagnostic 
standpoint. Through sophisticated conditional processing with a reliable 
engine advisor system, the additional sensor data could be acquired and used 
while at the same time lowering the false alarm rate below current levels. 

The data base survey task included in proposed follow on efforts would address 
the problems identified here. 

2.5.2.3 Analysis of Information Requirements 

There are three levels or types of analyses of information requirements related 
to the development of fault management systems. There is a top level analysis 
of fault management functions as they relate to other functional categories 
covering all air crew functions. NASA is supporting research in this area on 
other contracts. At the most detailed and specific level, there is the analysis of 
information required to diagnose faults. The results of this level of analysis 
could apply to either pilot information requirements or system information 
requirements. System information requirements represent the inputs needed 
in knowledge base development for engine monitoring and diagnosis activities 
carried out by an engine advisor system. Most of the effort in analyzing 
information requirements on the current project was focused at this level. A 
third type of information requirements analysis focuses on the type of 
information pilots need to make decisions about appropriate action to take 
given a particular fault/event combination. A conceptual framework for the 
analysis of this third type of information requirement was developed as a part 
of the present project. A description of the framework and results to date are 
contained in the next section. 

The information requirements analysis for the present study was data base 
driven. This meant that the analysis had to focus on specific faults for which 
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real engine data was available. There was little opportunity to expand the 
analysis to other faults beyond listing potential alternative faults which might 
lead to the same event. The number of such alternatives varied considerably 
across fault/event combinations. Being data driven also meant that we were 
forced to exclude several faults’ we would have liked to analyze for their 
contribution to the study of fault management but could not for lack of data. 
Examples of such faults were given earlier in the discussion of fault selection. 

The propagation sequence contained in the fault scenarios provided the basic 
inputs to the information requirements analysis. From this, an evaluation 
was made of the data that pilots have available without the aid of a Flight Deck 
Engine Advisor system. The quality of the data, pilot heuristics relevant to the 
fault, and any time constraints were also addressed. Information required to 
make a diagnosis was then analyzed. This served two purposes. It provided 
the core data required in knowledge base development and provided a basis for 
determining how much of a gap exists between information needs and 
information available. Little time was spent addressing this gap. To do so 
would have required an analysis involving the systematic consideration of 
context variables and level of automation. This was clearly beyond the scope of 
the present study. 

Because context variables can be useful in the diagnostic process as well as in 
decision making regarding alternative courses of action, subsections were 
included to address the application of context information to both diagnosis 
and action selection. The conceptual framework for application to action 
selection is discussed in detail in the next section. 

The complete text of each fault scenario developed is contained in Appendix A. 
It will be noted that the amount of information varies considerably across 
scenarios. This variation occurs for two reasons; the nature of the fault, and 
the availability of background data. Some faults such as "Hung Start-Ground" 
have a wealth of potential fault alternatives, a relatively slow propagation of 
the fault's effects, a clear key parameter in diagnosis, and straightforward 
relationships between context variables and action alternatives. Others such 
as "All Engine Flame out" which are based on flight data recorder output have 
a much more limited data base on which to draw for analysis. 
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The major limitation of the total fault scenario data base at present is the lack 
of comparable fault/event combinations for reliability checking and the lack of 
different fault/same event combinations to assess ability to distinguish among 
faults. The need for distinctions among faults must be determined in an 
analysis of the relationship between fault/event combinations, relevant context 
variables, and the resulting action alternative options. Such an analysis is 
proposed for a follow on effort. 

2.5.3 Event/Fault/Context/Action Relationships 

Understanding the event/fault/context/action relationships in fault detection 
and diagnosis is critical to designing the knowledge base to deal with them. 
This section provides a generic outline of the concepts being implemented in 
the Flight Deck Engine Advisor development effort. Most of the terms to be 
used have been defined in preceding sections. This section deals with the 
relationships. When specific examples are needed to illustrate points in this 
discussion, reference will be made to the Hung Start-Ground scenario in 
Appendix A. 


Figure 5 will provide a generic framework for the discussion of concepts and 
relationships. It also represents an attempt to illustrate what is meant by the 
"mapping of faults onto action alternatives". Events are used as the 
organizing concept in describing the relationship between faults, context 
variables, and action alternatives within a fault scenario. The event is shown 
on the left as in Figure 4 even though, in a propagation sense, faults precede 
events. 

Two additional terms are introduced in Figure 5 which need to be defined. 
Fault c a t egory is introduced at this point as an organizing concept. It may or 
may not play a role in rule-base development. Examples of these categories 
can be found in the Hung Start-Ground scenario under "Potential Fault 
Alternatives". For the hung start, they include pneumatic system failures, 
fuel system failures, procedure failures, etc. Context variable set refers to the 
context variables relevant to a fault and the status or value of each variable. 
With this definition, if one value for one variable in the set were to change, a 
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new set would be defined. This implies that the mapping of faults to action 
alternatives could change with the change of one value for one variable. 
Probably the best example of this are changes in phase of flight. 

The reader may refer to the contents of the Hung Start-Ground scenario for 
examples of everything shown in Figure 5. However, it should be noted that 
there is no correspondence intended between fault category letters, fault 
numbers, or action alternative labels and the actual material in the scenario. 

As can be seen, there are many faults which can produce the same event. The 
fault categories are used as an organizing concept in scenario development. It 
may be that most if not all faults within a category would map to a single 
action alternative thus forming a Fault/Action class. 

The concept of Fault/Action Classes is one introduced to reduce complexity in 
de fining the relationship between faults and action alternatives. For example, 
the line connections in Figure 5 show faults 1, 2, 3, 4, 5, 6, and 8 mapping onto 
action alternative Able. These faults would then constitute a Fault/Action 
class. This means that if any one of these faults occurred within the 
framework of a specific context variable set, the appropriate action alternative 
would be the same. Thus, diagnosis need only proceed to the point where the 
appropriate Fault/Action class has been identified. Other connections are 
shown between faults and action alternatives to illustrate that faults in a 
particular category may also map to very different action alternatives. The 
relationships depicted between faults in Category D and the action alternatives 
illustrate this situation. 

The wavy line descending from Context Variable Set through the fault/action 
connections is used to indicate that the pattern of connections may change 
considerably with different context variable sets. For example, changing 
phase of flight might have considerable effect on the mapping. It may become 
more complex, or in very high workload conditions may become highly 
simplified with only one or at most two alternatives being appropriate. 

So far, the picture suggests the potential for overwhelming complexity. It also 
suggests the myriad of factors which may or may not, should or should not 


34 


influence the pilots' decision-making process. As more real data are collected, 
the actual level of complexity to be dealt with will become clearer. 

Testing of the overall concept was not possible during the present contract due 
to a lack of appropriate data. We would like to exercise the MONITAUR and 
DRAPhyS modules with two different faults which result in a hung start (one 
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involving the fuel system and one the pneumatic system) during follow on 
work. If the monitoring and diagnostic modules can distinguish between the 
two (should such distinction be appropriate), we will have taken an important 
step in demonstrating the feasibility of the overall concept. 

Eventually we hope to be able to demonstrate the role of context variables in 
diagnosis by using rules based on context variable sets to prune fault 
hypotheses in the STAGE 1 diagnostic phase. As we gain knowledge about 
fault-fault and fault-action relationships, it may be possible to identify 
Fault/Action classes which are stable across most if not all context variable 
sets. It may also be possible to reduce the complexity of the knowledge base 
development process by pruning very low probability faults from consideration. 
These complexity reducing activities will remain as future research 
possibilities. 

To date, the beginnings of a data base on the relationship between fault/event 
combinations, context variables, and appropriate action alternatives has been 
included at the end of each fault scenario. Pilot information requirements for 
fault category management and flight planning would be an output of the 
context analysis proposed for a follow on effort. Specific requirements will be a 
function of the ev ent/fault/context/action relationships and level of automation 
in systems affected by the fault. 

2.6 TASK 6 - Identification of Pilot Information Requirements 

The task of analyzing information requirements was fully integrated into the 
fault scenario development process. A distinction between types of information 
requirements analysis was made in Section 2.5.2.3 to clarify the activities 
accomplished under the present contract and to relate these activities to other 
types of information requirements. Rationale for the type of information 
requirements analysis conducted was also included. The various categories of 
information developed and lessons learned in its compilation were also covered 
in that section. A further discussion of pilot information requirements was 
included in Section 2.5.3. 
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2.7 TASK 7 - Knowledge Base Development 

The Detailed Program Plan called for a minimum of effort expended on 
MONITAUR with a bulk of the development assigned to enhancement of 
DRAPhyS. Following the conversion of MONITAUR to GCLISP, several 
problems were encountered while modifying MONITAUR to accept the Boeing 
data and engine model. Initial efforts to generate symptoms consistent with 
those identified by propulsion experts using real fault data have emphasized to 
Boeing developers the importance of MONITAUR’s output to the entire 
diagnostic process. For this reason more emphasis has been placed on 
MONITAUR development than was originally anticipated. The goal was to 
identify and solve all issues required to produce accurate symptoms of Boeing 
supplied faults. The result of more effort expended on MONITAUR is less 
development completed for DRAPhyS. This reprioritization of effort was 
coordinated with and approved by the Technical Monitor. The details will be 
discussed by module below. 

2.7.1 Work in MONITAUR 

2.7.1.1 Conversion 

The first task was to convert MONITAUR code from Genera LISP on a 
Maclvory to GCLISP on a PC. All formatting was lost in porting from 
Macintosh to a PC since carriage returns are not recognized. Several software 
tools were created to pretty print each LISP function and the data structure 
found in LITTLEJENGINE. 

In addition to formatting problems there were several syntax incompatibilities 
as well. LOOP structures and SEND functions were unsupported in GCLISP, 
so recoding was required. Some changes were also made to eliminate 
warning messages in the LISP interpreter. Chief among these were function 
names beginning with semicolon. 

To enhance our understanding of MONITAUR processing, high level data 
flow diagrams for Faultfinder were constructed along with control flow charts 
for MONITAUR to capture the relationships between functions. 
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We also experienced some difficulty with GCLISP Developer Version 3.1 as a 
development environment. Incompatibilities between GCLISP version 3.1 and 
DOS 4.01 were difficult to identify. This problem occurred when Gold Hill was 
reorganizing as a corporation, thus technical support was a commodity 
difficult to find for a time. A beta copy of the enhanced MONITAUR was given 
to NASA during their Boeing review in September 1990. This software runs 
using GCLISP Developer version 3.1 under DOS 3.31. 

2.7.1.2 Using Real Fault Data 

After conversion, real fault data was obtained for a hung start and several 
degrees of engine icing. This data was supplied from a FORTRAN/APOLLO 
environment and had to be conditioned to conform to input currently used with 
MONITAUR. Utility programs were created to perform the data conditioning. 
These utilities allow the user to specify a selected time interval which contains 
the specific features which will generate symptoms. In addition, the size of 
the time slice can be set by the user within the limits of the granularity of the 
data supplied. Since each fault supplied by Boeing propulsion may come from 
a different flight source, all will have unique formats, so the conditioning 
utilities must be adapted for each fault. 

After conditioning was completed several trial runs were made with 
MONITAUR using the internal NASA engine model and Boeing fault data. A 
Boeing propulsion expert had identified specific symptoms for the faults 
supplied. A poor match was found with symptoms generated by these first 
experimental rims. MONITAUR generated extraneous symptoms and missed 
critical symptoms. No attempt was made to alter the internal NASA engine 
model. Instead modification of MONITAUR to accept a Boeing engine model 
data was initiated. The modified MONITAUR system includes a new f un ction 
which reads fault data from a file collected from sensors during flight 
(DATAFIL.DAT). This file is parsed to yield an actual value. 

2.7. 1.3 Using a Boeing Engine Model 

The original plan was to network a Boeing (APOLLO based) engine model with 
the PC version of MONITAUR to accept engine model data on a time slice 
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basis. When it was discovered that this strategy violated Boeing propulsion’s 
engine model distribution policy, an alternate plan was devised which used 
data generated by propulsion in a batch mode matching the fault data file. 

New LISP functions to parse the engine model data file were created and 
substituted for calls to the internal engine model. The modified MONITAUR 
system consists of a program which reads this model data from a file 
(MODEL.FIL) which yields an expectation value. Experimental runs were 
made using Boeing fault data and Boeing engine model data. The results were 
improved, but not perfect when compared with symptoms identified by experts. 

2.7. 1.4 Additional Modifications 

Modifications to the MONITAUR code were made to reduce differences 
between expected symptoms and generated symptoms. An algorithm change 
in trend calculation yielded more consistent trend symptoms. 

An additional concern about noise levels for each sensor for each parameter 
(actual value, deviation, and trend) was identified. The design of MONITAUR 
is excellent in that it allows individual noise levels to be set for each sensor for 
each par am eter. A task was defined to utilize healthy engine data to compare 
with a Boeing engine model to yield initial noise levels. The issue was to be 
able to set values high enough to eliminate spurious symptoms yet low enough 
to not miss significant symptoms. The comparison of engine model data with 
data collected from healthy engines yielded values for noise. These were coded 
into the Physical System File (PSF) for the engine model selected. A 
comparison of healthy engine data with expectation data produced about 30% 
fewer spurious symptoms when the custom PSF was used. 

A third area of concern was the MONITAUR knowledge base which is used to 
filter symptoms generated solely due to engine model behavior, and are not 
real performance symptoms. The original plan was to not address 
modifications in the MONITAUR knowledge base, but our work with 
diagnostics has shown the tremendous importance of being able to generate 
symptoms with very high reliability. The bottom line is that without extremely 
accurate symptoms, the diagnostic phase development is worth very little. 
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This reasoning prompted the Boeing developers to elevate the priority of 
spurious symptom analysis to a much higher status. A second engine (from a 
different manufacturer) was examined to insure the problem was generic. A 
second PSP was customized for the new engine and heathy data was analyzed. 
Consistent spurious symptoms were detected for both engines. Analysis of 
both engine s spurious symptoms was completed. Several sources of spurious 
symptoms were identified. These were documented and forwarded to NASA in 
November 1990. 

For each source of spurious symptom documented, an analysis of potential 
solutions was also provided. From December 1990 to present the major 
developmental effort for MONITAUR has been to investigate a subset of the 
alternatives suggested to determine effectiveness of the selected alternative. 
Several new LISP functions were written and tested to support new symptom 
filtering rules for the PSF . A significant reduction in spurious symptoms has 
been achieved, but we have not addressed each alternative, nor even each 
source. A large part of our follow-on recommendation will be to find an 
optimal solution to spurious symptoms generation. The work accomplished to- 
date can be considered proof-of-concept for spurious symptom reduction. 


2.7. 1.5 Output from MONITAUR 

There are three levels of output from MONITAUR. The first, and most 
voluminous, is the "encyclopedia run" for each fault and healthy engine file. 
This file shows the state of each sensor for each time slice along with every 
symptom generated. It also contains the numbers of filtering rules fired as the 
symptom was analyzed. 

A sample set of "encyclopedia" output is shown in Figure 6. It shows a time 
slice identified by its time value, in this case "237". Prior to evaluating the 
actual and expectation data, five filtering rules from the MONITAUR 
knowledge base fired, #7, #9, #10, #11, and #12. These rules resulted in five 
potential symptoms not being passed to DRAPhyS STAGE2. The state of each 
sensor is then printed, first the actual, then the expectation states. Following 
the states of the actual and expectation data, the symptoms discovered by 
MONITAUR are printed. In the case of Nl, the difference between the actual 
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static (NORMAL) and the expectation static (LOWER-CAUTION) yield a static 
symptom of HIGHER-THAN-EXPECTED. Each sensor can potentially have 
three symptoms (Static symptom, Derivative symptom, and Trend Symptom) 
generated. When all three actual states agree with all three expectation states, 
no symptoms are generated, as’ shown in the ALTITUDE sensor. We will use 
this same time slice in the discussion of output files in the following 
paragraphs. 
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I rule 7 fired" 

rule 9 fired" 
rule 10 fired" 
rule 11 fired" 

" " rule 12 fired" 

For Time 237.0: " 

SENSOR: N1 

The following symptoms reflect the actual data. 
Static Symptoms: (NORMAL) 

Derivative Symptoms: (INCREASING) 

Trend Symptoms: (INCREASING) 

The following symptoms reflect the expected values. 
Static Symptoms: (LOWER-CAUTION) 

Derivative Symptoms: (INCREASING) 

Trend Symptoms: (INCREASING) 

The following symptoms reflect differences between 
the actual data and the expected values. 

Static Symptoms: (HIGHER-THAN-EXPECTED) 

3ENSOR: N2 

The following symptoms reflect the actual data. 
Static Symptoms: (NORMAL) 

Derivative Symptoms: (INCREASING) 

Trend Symptoms: (INCREASING) 

The following symptoms reflect the expected values. 
Static Symptoms: (NORMAL) 

Derivative Symptoms: (INCREASING) 

Trend Symptoms: (INCREASING) 

The following symptoms reflect differences between 
the actual data and the expected values. 

Static Symptoms: (HIGHER-THAN-EXPECTED) 

SENSOR: EGT 

The following symptoms reflect the actual data. 
Static Symptoms: (NORMAL) 

Derivative Symptoms: (INCREASING) 

Trend Symptoms: (INCREASING) 

The following symptoms reflect the expected values. 
Static Symptoms: (NORMAL) 

Derivative Symptoms: (INCREASING) 

Trend Symptoms: (INCREASING) 

The following symptoms reflect differences between 
the actual data and the expected values. 

Static Symptoms: (HIGHER-THAN-EXPECTED) 

ENSOR: EPR 

The following symptoms reflect the actual data. 

Static Symptoms: (NORMAL) 

Derivative Symptoms: (INCREASING) 

Trend Symptoms: (INCREASING) 

The following symptoms reflect the expected values. 
Static Symptoms: (NORMAL) 

Derivative Symptoms: (INCREASING) 

Trend Symptoms: (STEADY) 

The following symptoms reflect differences between 
the actual data and the expected values. 

Trend Symptoms: (INCREASING- ABNORMALLY! 


43 


SENSOR: FUEL-FLOW 

The following symptoms reflect the actual data. 

Static Symptoms: (NORMAL) 

Derivative Symptoms: (INCREASING) 

Trend Symptoms: (INCREASING) 

The following symptoms reflect the expected values. 

Static Symptoms: (NORMAL) 

Derivative Symptoms: (INCREASING) 

Trend Symptoms: (INCREASING) 

The following symptoms reflect differences between 
the actual data and the expected values. 

Static Symptoms: (HIGHER-THAN-EXPECTED) 

SENSOR: ALTITUDE 

The following symptoms reflect the actual data. 

Static Symptoms: (NORMAL) 

Derivative Symptoms: (STEADY) 

Trend Symptoms: (STEADY) 

The following symptoms reflect the expected values. 

Static Symptoms: (NORMAL) 

Derivative Symptoms: (STEADY) 

Trend Symptoms: (STEADY) 

SENSOR: MACH 

The following symptoms reflect the actual data. 

Static Symptoms: (NORMAL) 

Derivative Symptoms: (STEADY) 

Trend Symptoms: (STEADY) 

The following symptoms reflect the expected values. 

Static Symptoms: (NORMAL) 

Derivative Symptoms: (STEADY) 

Trend Symptoms: (STEADY) 

SENSOR: THROTTLE 

The following symptoms reflect the actual data. 

Derivative Symptoms: (INCREASING) 

Trend Symptoms: (INCREASING) 

The following symptoms reflect the expected values. 

Derivative Symptoms: (INCREASING) 

Trend Symptoms: (INCREASING) 

Figure 6. ’’Encyclopedia' 1 Output from MONITAUR 
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In addition, an output, file is created for STAGE 1 of DRAPhyS and for STAGE2 
of DRAPhyS. The STAGE 1 output consists of all sensor states and symptoms 
generated from MONITAUR. 

A sample of the STAGE1 input file is shown in Figure 7. It is a file with the 
format 

( 

(time (sensorl) (sensor2)...) 

(time (sensorl) (sensor2)...) 

♦ 

) 

The first time slice shown is identified with the time value "237.0". Following 
the time is a list of sensor states and symptoms for each sensor in the Physical 
System File. This file can be passed as a list of time slices for batch processing 
by STAGE 1, or as individual time slices and processed sequentially in unison 
with MONITAUR. 
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(237.0 

(THROTTLE 

((STABILITY-EQT (INCREASING))"(STATUS-OF-DERIVATIVE-EQD (INCREASING)) 
(STABILITY-AQT (INCREASING)) (STATUS-OF-DERIVATIVE-AQD (INCREASING)))) 
(MACH 

((STABILITY-EQT (STEADY)) (STATUS-OF-DERIVATIVE-EQD (STEADY)) 

(STATUS-0 F-VALUE-EQS (NORMAL)) (STABILITY-AQT (STEADY)) 
(STATUS-OF-DERIVATIVE-AQD (STEADY)) (STATUS-OF-VALUE-AQS (NORMAL)))) 
(ALTITUDE 

((STABILITY-EQT (STEADY)) (STATUS-OF-DERIVATIVE-EQD (STEADY)) 
(STATUS-OF-VALUE-EQS (NORMAL)) (STABILITY-AQT (STEADY)) 
(STATUS-OF-DERIVATIVE-AQD (STEADY)) (STATUS-OF-VALUE-AQS (NORMAL)))) 
(FUEL-FLOW 

((STATUS-OF-VALUE-DQS (HIGHER-THAN-EXPECTED)) (STABILITY-EQT 
(INCREASING)) 

(STATUS-OF-DERIVATIVE-EQD (INCREASING)) (STATUS-OF-VALUE-EQS (NORMAL)) 
(STABILITY-AQT (INCREASING)) (STATUS-OF-DERIVATIVE-AQD (INCREASING)) 
(STATUS-OF-VALUE-AQS (NORMAL)))) 

(EPR 

((STABILITY-DQT (INCREASING-ABNORMALLY)) (STABILITY-EQT (STEADY)) 
(STATUS-OF-DERIVATIVE-EQD (INCREASING)) (STATUS-OF-VALUE-EQS (NORMAL)) 
(STABILITY-AQT (INCREASING)) (STATUS-OF-DERIVATIVE-AQD (INCREASING)) 
(STATUS-OF-VALUE-AQS (NORMAL)))) 

(EGT 

((STATUS-OF-VALUE-DQS (HIGHER-THAN-EXPECTED)) (STABILITY-EQT 
(INCREASING)) 

(STATUS-OF-DERIVATIVE-EQD (INCREASING)) (STATUS-OF-VALUE-EQS (NORMAL)) 
(8TAB TT.T TY.AQT (INCREASING)) (STATUS-OF-DERIVATIVE-AQD (INCREASING)) 
(STATUS-OF-VALUE-AQS (NORMAL)))) 

(N2 

((STATUS-OF-VALUE-DQS (HIGHER-THAN-EXPECTED)) (STABILITY-EQT 
(INCREASING)) 

(STATUS-OF-DERIVATIVE-EQD (INCREASING)) (STATUS-OF-VALUE-EQS (NORMAL)) 
(STABILITY-AQT (INCREASING)) (STATUS-OF-DERIVATIVE-AQD (INCREASING)) 
(STATUS-OF-VALUE-AQS (NORMAL)))) 

(N1 

((STATUS-OF-VALUE-DQS (HIGHER-THAN-EXPECTED)) (STABILITY-EQT 
(INCREASING)) 

(STATUS-OF-DERIVATIVE-EQD (INCREASING)) 

(STATUS-OF-VALUE-EQS (LOWER-CAUTION)) (STABILITY-AQT (INCREASING)) 
(STATUS-OF-DERIVATIVE-AQD (INCREASING)) (STATUS-OF-VALUE-AQS 
(NORMAL))))) 
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(238.0 
(THROTTLE 

((STABILITY-EQT (INCREASING)) (STATUS-OF-DERIVATIVE-EQD (INCREASING)) 
(STATUS-OF-V ALUE-EQS (FULL)) (STABILITY-AQT (INCREASING)) 
(STATUS-OF-DERIVATIVE-AQD (INCREASING)) (STATUS-OF-VALUE-AQS (FULL)))) 
(MACH 

((STABILITY-EQT (STEADY)) (STATUS-OF-DERIVATIVE-EQD (STEADY)) 
(STATUS-OF-VALUE-EQS (NORMAL)) (STABILITY-AQT (STEADY)) 
(STATUS-OF-DERIVATIVE-AQD (STEADY)) (STATUS-OF-VALUE-AQS (NORMAL)))) 
(ALTITUDE 

((STABILITY-EQT (STEADY)) (STATUS-OF-DERIVATIVE-EQD (STEADY)) 
(STATUS-OF-VALUE-EQS (NORMAL)) (STABILITY-AQT (STEADY)) 
(STATUS-OF-DERIVATIVE-AQD (STEADY)) (STATUS-OF-VALUE-AQS (NORMAL)))) 
(FUEL-FLOW 

((STABILITY-EQT (INCREASING)) (STATUS-OF-DERIVATIVE-EQD (INCREASING)) 
(STATUS-OF-VALUE-EQS (NORMAL)) (STABILITY-AQT (INCREASING)) 
(STATUS-OF-DERIVATIVE-AQD (INCREASING)) (STATUS-OF-VALUE-AQS (NORMAL)))) 
(EPR 

((STABILITY-EQT (INCREASING)) (STATUS-OF-DERIVATIVE-EQD (INCREASING)) 
(STATUS-OF-VALUE-EQS (NORMAL)) (STABILITY-AQT (INCREASING)) 
(STATUS-OF-DERIVATIVE-AQD (INCREASING)) (STATUS-OF-VALUE-AQS (NORMAL)))) 
(EGT 

((STATUS-OF-DERrVATIVE-DQD (NOT-INCREASINGAS-FAST-AS-EXPECTED)) 
(STABILITY-EQT (INCREASING)) (STATUS-OF-DERIVATIVE-EQD (INCREASING)) 
(STATUS-OF-VALUE-EQS (NORMAL)) (STABILITY-AQT (INCREASING)) 
(STATUS-OF-DERIVATIVE-AQD (STEADY)) (STATUS-OF-VALUE-AQS (NORMAL)))) 

(N2 

((STATUS-OF-VALUE-DQS (HIGHER-THAN-EXPECTED)) (STABILITY-EQT 
(INCREASING)) 


Figure 7. STAGE1 Input Sample 
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The STAGE2 output consists of filtered symptoms from MONITAUR. A 
sample of the STAGE2 input file is shown in Figure 8. It is a file with the 
format 
( 

((sensorl) (sensor2) (sensor3) ...) 

) 

Each of the elements of the file is a list of sensor symptoms for one time slice. 
Each sensor entry is a list in a format expected by the function 
ADD_SYMPTOM from STAGE2. The first time slice shown is time 200. There 
are no STAGE2 symptoms for this time slice, so the entry is NIL. Examination 
of time slice 233 shows it is reporting sensor symptoms for N2. Examination of 
time slice 237 will show it is reporting sensor symptoms for EGT, but the other 
sensor symptoms shown in the "encyclopedia" run were filtered out as 
spurious symptoms. 
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( 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

NIL 

((N2 NIL (NORMAL) NIL NIL 233.0 (STEADY))) 

((EPR NIL (NORMAL) NIL NIL 234.0 (STEADY)) (EGT NIL (NORMAL) NIL 
NIL 234.0 (STEADY)) (N1 NIL (LOWER-CAUTION) NIL NIL 234.0 (STEADY))) 
((EGT NIL (NORMAL) NIL NIL 235.0 (STEADY))) 

NIL 

((EPR NIL (NORMAL) NIL NIL 237.0 (INCREASING))) 

((EGT NIL (NORMAL) NIL NIL 238.0 (INCREASING))) 

((EGT NIL (NORMAL) NIL NIL 239.0 (INCREASING))) 

((EGT NIL (NORMAL) NIL NIL 240.0 (STEADY))) 

((EGT NIL (NORMAL) NIL NIL 241.0 (STEADY))) 

((EGT NIL (NORMAL) NIL NIL 242.0 (STEADY))) 

«N2 NIL (NORMAL) NIL NIL 243.0 (INCREASING))) 

((N2 NIL (NORMAL) NIL NIL 244.0 (INCREASING))) 

((EGT NIL (NORMAL) NIL NIL 245.0 (INCREASING)) (N2 NIL (NORMAL) NIL 
NIL 245.0 (INCREASING))) 

((EPR NIL (NORMAL) NIL NIL 246.0 (STEADY)) (EGT NIL (NORMAL) NIL 
NIL 246.0 (INCREASING))) 

((EGT NIL (NORMAL) NIL NIL 247.0 (INCREASING))) 

Figure 8. STAGE2 Input Sample 
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2.7. 1.6 Lessons Learned on MONITAUR 

As reflected in the previous section, the most important lesson learned is to 
recognize how vital an accurate set of symptoms is to the remainder of the 
system. At this point in the development it seems like an obvious fact, but the 
result is that we felt it was important to expend more than anticipated effort on 
MONITAUR to insure a valid set of symptoms are identified. 

It is also obvious that more effort must be expended to minimize the number of 
spurious symptoms. Identification of spurious symptoms is readily achieved 
by processing healthy engine data through MONITAUR and looking for am 
symptom output. To date seven different files of healthy engine data have been 
examined representing about 900 seconds of engine run time. This represents 
about 900 time slices under normal query frequency. The analysis of these 
symptoms for source is more complex. About 70% of the time expended in our 
spurious symptom investigation was used for analysis. Several categories of 
symptoms were identified. Another 30% of effort was expended in coding and 
testing a subset of potential solutions for these symptom categories. At this 
point in the study, we believe the list of categories is incomplete and only a 
limited success in spurious symptom elimination has been achieved. It is 
estimated that four man months of total effort has been devoted to spurious 
symptom investigation. The goal of spurious symptom reduction will be a 
major portion of a follow-on contract. It is estimated that five to ten times as 
much data will be required for closure on this topic. 

What is not so apparent, is how many spurious symptoms are generated by 
differences in individual (serial number) engines. Boeing propulsion 
estimates these differences may approach 30% for some sensors. Elimination 
of spurious symptoms with known causes will help to identify a reasonable 
value for those whose source is individual engine differences. 

There is a potential to greatly enhance the quality of valid symptoms. 
Preliminary work on valid symptom analysis suggests that some valid 
symptoms may be temporally conditioned. For example, if the expectation 
value is much lower than the actual value so as to generate a static symptom, 
but the derivative and trend of the expectation value is much higher than the 
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actual, the expectation value may be trying to "catch up" with the actual value. 
In this case it may be^ better to delay a static symptom generation for a few time 
slices. Exactly how to inhibit this symptom is a topic of investigation. Rules 
can be written for the MONITAUR filter to inhibit symptom generation, but 
another alternative is to consider differing classes of symptom - perhaps a 
warning class for stable symptoms and a caution class for a "catch up" 
situation as described above. The topic of symptom enhancement should 
definitely be studied further. 

There is also evidence that the duration of time slice taken may affect 
symptoms and that heuristics might be developed to dynamically select time 
slice duration for each sensor as a function of developing conditions. The cost 
of redesigning the data structures required to provide unique time slices for 
each sensor would have to be evaluated and compared with the value of higher 
fidelity sensor behavior. 

2.7.2 Work in DRAPhyS STAGE1 

2.7.2. 1 Conversion 

The work done on DRAPhyS STAGE 1 began with conversion from Genera 
LISP To GCLISP with problems similar to those discussed in 2.7.1. 1. 

Following conversion, the system was tested using the rule base supplied with 
the NASA version. The interactive function was utilized to enter symptoms 
and basic functionality of STAGE 1 was verified. A decision was made not to 
attempt to extend the STAGE 1 knowledge base until real symptoms from 
MONITAUR could be input to DRAPhyS STAGE 1. 

2.7.2. 1.1 Analysis of STAGE1 

Before extending the knowledge base or accepting any output from 
MONITAUR, a better knowledge of how STAGE 1 functioned was needed. An 
analysis of what each function did and its relationship to the other functions in 
STAGE 1 was performed. To further clarify STAGE 1, a detailed flow chart was 
constructed for all of the functions that were used in STAGE 1. 
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Examining the results of the analysis program and the detailed flow chart 
revealed that three functions, INIT-STAGE1, INTERACT and START form 
the core of STAGE1. To pull these three functions together, a shell that 
accommodated the three core functions and the user was written for batch file 
processing (discussed below in section 2.7.2.2). The shell, RUN-STAGE 1, is 
called by the LOAD function. RUN-STAGE1 calls INIT-STAGE1 and informs 
the user that STAGE 1 is initialized. It then allows the user to choose between 
the interactive mode (call INTERACT) or the automatic mode (call START2). 
After STAGE 1 has completed its run, the shell allows the user to rerun 
STAGE 1, remain in LISP, return to the operating system or terminate the 
session. 

Next, the analysis showed that there were six functions that were neither 
called by other functions or called other functions. These functions are used in 
temporal reasoning and are listed below. 

STARTS 

FINISHES 

BEFORE 

OVERLAP 

MEETS 

DURING 

There are two other temporal reasoning functions in STAGE1, TMPRL and 
TMPRL-AUX. These two functions make use of the six temporal function 
listed previously, but the function TMPRL requires that it be called by the user. 
This means that temporal reasoning is not presently used in STAGE 1 
diagnostics unless it is called by the user. The nature of the gas turbine engine 
and the way events occur during its operation triggered further examination of 
the MONITAUR output data. The results of this examination indicate that 
temporal reasoning could be an important part of the analysis and diagnostic 
process 

In using STAGE 1 in the interactive mode, it was discovered that the WHY and 
SHOW functions did not work. This problem was not pursued because 
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building a rule base for STAGE 1 had a higher priority and these functions 
appear to have no use in an integrated system. 

2.7. 2.2 Integration of DRAPhyS STAGE 1 with MONITAUR 

Two approaches for integration were evaluated. The first was to generate a file 
of symptoms for multiple time slices from MONITAUR and use these as a 
batch input to DRAPhyS STAGE1. This offers advantages of being able to test 
changes in STAGE 1 without running MONITAUR. Most of the analysis 
described in this report was performed using the batch method. A second 
alternative was to load both MONITAUR and DRAPhyS STAGE1 and 
sequentially call STAGE 1 for evaluation after each symptom set is generated 
for each time slice. Both approaches have been developed. The latter approach 
was developed since it more closely represents the processing required for a 
real time system and offers a greater technical challenge in terms of allocating 
PC resources. 

MONITAUR was modified to produce a data structure which will eventually 
be passed to STAGE 1 for parsing into symptoms. Initially, however, this 
structure was written as an output from MONITAUR for each time slice. The 
file is then read into STAGE1 for parsing and analysis. The main reason for 
the interim file is to allow an audit trail for system debugging. 

To accommodate running the output from MONITAUR, changes to STAGE 1 
were required. Specifically, the function START was modified twice. The first 
modification, START1, is used for the integrated version. The second 
modification, START2, is used for batch processing. START2 allows the user 
to name the file to be processed. While it is analyzing each time slice the 
results of the analysis are printed to the screen. The results of each session is 
saved in a file named by the user. 

2.7.2.2.1 Using MONITAUR Output Data In STAGE 1 

MONITAUR's output consists of a data structure for each time slice generated 
by the Boeing engine model. Each time slice contains data for up to eight 
sensors. The sensors are Nl, N2, EGT, EPR, FUEL-FLOW, ALTITUDE, 


53 



MACH and THROTTLE. For each sensor there can be up to nine pieces of 
more detailed data. They are Actual - static, derivative and trend; Expectation 
- static, derivative and trend and Deviation - static, derivative and trend. 

For batch processing MONITAUR output data is input to STAGE 1 via a floppy 
disk file. Hard copies of the files were available in the form of an encyclopedia 
and a print out of the disk file. The number of time slices for each file ranged 
from forty five to one hundred eighty. Given the number of time slices and the 
preponderance of data for each time slice, interpretation of the data was 
difficult. To solve this problem, a program was written that displays the data 
in an abbreviated format. This is a matrix type form with a row for each time 
slice and a column for each sensor name. Presently, only five sensors are 
displayed; Nl, N2, EGT, EPR and FUEL-FLOW. To further simplify the 
analysis, only the three Deviations are shown for each time slice/sensor 
combination. Using the abbreviated format has greatly simplified analysis of 
this data and building rules for STAGE1. 

2.7.2.3 Adding New Rules to DRAPhyS STAGE 1 

Rules for Boeing identified faults were developed as a part of the fault scenario 
development activity. Four rules have been added to STAGE 1 during the 
second half of the project. These rules are based on the work of knowledge 
engineers working with experts using actual flight data from Boeing files. 

Analysis of Symptom Data 

To date six files have been output from MONITAUR. They are Healthy- 
EngineA, Healthy-EngineB, Ground-Hung-Start, Light-Ice, Moderate-Ice and 
Heavy-Ice. Each of these files was passed through the program that produced 
the abbreviated symptom report. 
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Analysis of MONITAUR Ontnnt 
Healthy-Engine 

It would be expected that both Healthy-Engine outputs from MONITAUR 
would contain little if any symptom data, but this is not so. Both reports 
showed about 10% of the spaces contained symptom data. This is quite high 
considering that an engine with known faults i.e. Light-Ice, had a symptom 
population of about 6%. These spurious symptoms were discussed in detail in 
section 2.7. 1.4. 

Ground-Hung-Start 

Hung starts can occur both on the ground and in the air, and can result from a 
number of different causes. The experts provided us with data for a ground 
hung start. The hung start was caused by a fuel metering unit malfunction, 
providing too little fuel to the fuel nozzles. It was found that the fuel valve 
either moved to a partially open position and stuck or failed to move from the 
minimum open position. This resulted in insufficient combustion to support 
normal spool-up to idle. 

The experts report stated that at time t3, fuel flow began to drop below the flow 
rate for normal start. In addition N2 rotor speed began to lag below normal 
rate. N1 and EGT remained normal at this time. At time t4, N2 and EGT did 
not reach normal values and N1 leveled at 53% of normal. EGT was 
increasing at the normal rate. At t5 N2 should have been at idle speed, but was 
at only 67% of idle RPM. EGT was still normal. At t6 N1 and N2 were still at 
below normal speeds, and EGT continued to increase to 13% above normal, 
instead of leveling off. 

A rule set was constructed for ground hung start using the data supplied by 
the experts. The rule set was tested against the output data from MONITAUR 
and fired successfully when the data indicated a hung start. 


55 


Light-Ice 


An y ingestion of foreign matter such as birds, volcanic ash, or ice is classified 
as foreign object damage (FOD). In the case of light-ice damage, FOD results 
in an step-function change in the level of vibration produced by the engine, 
while all other parameters remain relatively normal. The effect of damage 
anH the resulting thrust shortfall may be so subtle that it would not be detected 
by the crew until the throttle is advanced for take-off or go-around (TOGA) 
power (advancing the throttle). 

The output from MONITAUR for light-ice damage comes close to verifying 
this. The only real deviation from this is the Higher-Than-Expected EGT. 

This may be due to a number of factors, from the age of the engine to problems 
with the model. Because vibration data is not normally collected, and the lack 
of other symptom data produced by MONITAUR, no rules were constructed for 
light-ice. 

Moderate-Ice 

The symptoms for moderate ice damage differ depending on the commanded 
power setting. The two power settings observed were climb and cruise. 

In the climb setting, N1 speed was on target while N2 showed a decrease of 5%. 
Both EGT and Fuel-Flow fell slightly below expected value. As in low ice 
damage, these shortfalls could be difficult for the crew to observe. Also, the 
vibration level on N1 exceeded the expected value by 25%. A spike appeared in 
N2 vibration reading, then it dropped to the expected value. 

In the cruise setting, thrust shortfall increased slightly from climb setting. N2 
was at the expected level. EGT and Fuel-Flow remained slightly lower than 
expected. N1 vibration remained at 25% above expected value, but N2 vibration 
reading was averaging 200% higher than expected value. Acceleration to the 
commanded thrust level was slightly slower than expected. 

The output from MONITAUR for moderate-ice damage is difficult to interpret 
for three reasons. First, sensor data for any given series of time slices is not 
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consistent. Second, symptoms differ between modes of operation, i.e., climb 
and cruise. Third, vibration data is not available from MONITAUR, and 
vibration, as with low ice damage seems to be the only clear indication of 
damage in an FOD situation. The other indications (EGT, N2 speed and Fuel- 
Flow) are subtle and may not be noticed in the cockpit. In addition, these 
differences could fall within the noise bands of MONITAUR deviation detection 
and not appear in the symptom file. Due to these reasons, no rules were 
constructed for moderate ice damage. 

Heavy Ice 

While changes in vibration levels on low (Nl) and high (N2) speed rotors are 
evident with light and moderate ice damage, they do not show up with heavy 
damage. Instead, the vibration symptom evident for heavy damage is a 
marked increase in broad band vibration. In addition, the shortfall with light 
ice damage is only evident under TOGA power settings. Moderate ice damag e 
results in a slight shortfall at climb power. But, with heavy ice damage, the 
shortfall is very evident even at cruise power (i.e., approximately 80% of 
normal). N2 was lower than expected, and both EGT and Fuel-Flow were 
lower than expected. 

The output from MONITAUR for heavy ice damage is heavily populated with 
symptom data and compares closely with the expert's statement. The only 
disagreement is in EPR and Fuel-Flow. MONITAUR shows EPR lower than 
expected and no Deviation for Fuel-Flow for the first eighteen time slices. It 
then shows Fuel-Flow increasing until time slice 60.5. At time 61.0, it begins 
to decrease till time 69.0, after that it remains normal. The experts statement 
shows lower than expected for both EPR and Fuel-Flow. The reasons for this 
discrepancy are still being investigated. 

Based on the expert’s information a set of rules was built for Heavy Ice 
damage. However, the data concerning Fuel-Flow was left out of the rule set 
pending further investigation into the problem. The rule set was tested 
against the MONITAUR output and was successful in firing when Heavy Ice 
damage was indicated. 
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2.7.2A Alternate DRAPhyS STAGE1 Development 

An alternate to DRAPhyS STAGE1 was also examined. In an attempt to allow 
STAGE 1 processing on incomplete symptom information, a fault pruning 
paradigm was created using NEXPERT OBJECT, A knowledge base 
consisting of an object architecture and a rule base were designed to allow 
incremental knowledge to be accumulated with a corresponding incremental 
reasoning about the associated faults). The paradigm consists of an object 
architecture with a set of faults modeled with associated properties. The rule 
base examines the current set of symptoms and dynamically prunes potential 
faults from the object architecture using negative evidence. Thus as the set of 
symptoms is developed, the list of possible faults is diminished. The advantage 
of this approach is the development of partial knowledge with incomplete 
evidence (as opposed to conventional approach which only fires rules when 
complete knowledge is available). 

The status of this alternative is a current working demo with information 
modeled from a NASA supplied rule base. This demo lacks fidelity, and is not 
a proof of concept. It was demonstrated to NASA in September 1990 as a 
potentially more robust approach to conventional STAGE 1 processing. No 
further development on this alternative is anticipated unless specifically 
requested by NASA. 

2.7.2. 5 Lessons Learned on DRAPhyS STAGE1 

1. More data is needed to ensure the fidelity of rules generated in STAGE1. 
Multiple incidences of the same fault and an expanded range of faults 
are both required. Each individual engine is different from the next. In 
addition, as engines age, their operational characteristics change. And 
finally, any repair or adjustment made to an engine, during routine 
maintenance or unscheduled maintenance, can change its operational 
characteristics. Thus, more comparisons are needed to establish the 
reliability and validity of the diagnostic process. 

A solution to the above problem is to collect data and create separate data 
files for different engines and measure differences between engines. 
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The analysis should take into consideration the fact that as the engine 
accumulates operation time, its operation characteristics will change, 
therefore, operating time of the engine should by collected by the system. 

2. Diagnosing with symptoms from only one time slice at a time is not 
effective. Engine failures and problems are progressive in nature. A 
complete set of symptoms do not occur all at once. They may occur one 
or two at a time, or a new symptom may take the place of the previous 
symptom. Symptoms may also by intermittent and/or transient and go 
away. 

Building a history of sensor symptoms for each time slice and analyzing 
them with temporal reasoning to see if they match a rule, would be a 
more realistic type of diagnosis. Both data collection and accumulation, 
and diagnosis would occur in the same time slice. 


Data could be collected by MONITAUR and analyzed in a three 
dimensional matrix. Each plane of the matrix would be a fault file in 
the matrix format described in section 2.7.2.3. Each file produced by 
MONITAUR could be analyzed for the number of symptoms it holds. 
Symptoms may occur in clusters or groups; certain symptoms within 
time slice by sensor cells of the matrix may form patterns that could be 
built into rules. The data could be analyzed for symptom trends which 
could be used for early detection of problems. The data for one 
operational period could be compared with data from other operational 
periods to establish trends in symptom occurrence. And finally, the 
data used to build possible rules could be compared with the data that 
was used to build existing rules. This would prevent building identical 
rules for different failures. 

If a failure occurs during operation, and the collected data did not 
match a rule, it may be possible that the data could be analyzed to 
determine an alternate or additional symptom for the failure. This may 
be another way to use collected data to build rules. 
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4. Include altitude, Mach, and throttle sense data in the data analyzed by 

STAGE!. Analysis of present symptom data shows that symptoms 
change during different phases of flight and engine operation. The 
symptoms for FOD in climb are different from the FOD symptoms in 
cruise. In fact, the total' engine operational characteristics could 
change during different phases of flight and engine operation. 

These different phases of flight and engine operation could be detected by 
monitoring actual altitude, Mach and throttle settings. This data would 
also be included in the rules. 

There are some factors, not previously considered within the scope of this 
study, which may have a significant bearing on the Boeing perspective. One of 
these is the response required for the fault. If there are a limited number of 
valid responses to all engine faults, perhaps diagnosis does not have to be 
accomplished to the granularity previously defined. It may be that STAGE1 
only needs to associate symptoms with classes of faults in order to generate the 
correct response to the problem. These issues will not be addressed in the 
current contract, but should be noted for further study. They also suggest that 
STAGE 1 (associational) processing may not be as dependent on fault specificity 
as originally thought. 

2.7.3 Work in DRAPhvS STAGE2 

Work completed on DRAPhyS STAGE2 began with a Boeing analysis of the 
model based paradigm utilized in this NASA- developed module. As an initial 
effort to gain understanding of the software, high level data flow diagrams and 
control flow charts have been constructed to document the system 
functionality. The demonstration system supplied by NASA was installed and 
made functional on Boeing hardware. This demonstration program is a 
stand-alone interactive system with symptoms input through mouse selection 
from a GUI or by using text based LISP functions. Boeing's first objective was 
to create a connection from the output from MONITAUR, which is a list of 
symptoms, to the DRAPhyS STAGE2 program. 

2.7.3. 1 Development Strategy for DRAPhyS STAGE2 
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Since DRAPhyS STAGE2 contains extensive use of Flavors, which is not 
supported in GCLISP, conversion to GCLISP was not an option. To make 
STAGE2 compatible with the PC versions of MONITAUR and DRAPhyS 
STAGE1, two alternatives wer6 considered. The first was to develop a stand 
alone version of STAGE2 on the Maclvory under Genera LISP which is CLOE 
compatible. When the desired functionality could be demonstrated on the 
Maclvory, the code would be ported to a PC using CLOE. A run time version 
would then be completely PC based. A second alternative (not implemented) 
was to leave the development on the Maclvory workstation and network the PC 
with MONITAUR output to the Maclvory for STAGE2 processing. 

2.7.3.2 STAGE2 Development 

DRAPhyS STAGE2 was redeveloped to a PC-connectable module capable of 
accepting symptom input from MONITAUR using CLOE. Minor 
modifications were made to DRAPhyS STAGE2 for the CLOE version. Most 
were syntax incompatibilities between CLOE LISP and Genera LISP. Just as 
the development of PC versions of MONITAUR and DRAPhyS STAGE1 with 
real fault and Boeing engine model input led to discovery of issues of concern 
and strategies for further development, STAGE2 yielded similar concerns and 
strategies. The CLOE version of STAGE 2 was modified to accept input from 
the MONITAUR program. The data can be passed to STAGE2 in a time slice 
format or in a batch mode consisting of multiple time slices. 

A major concern was the effect of spurious symptoms in the DRAPhyS 
STAGE2 system. Current STAGE2 processing allows no symptom evaluation. 
Each symptom is processed as valid and appropriate fault hypotheses are 
generated and tested. For this reason, extensive symptom evaluation must be 
completed in MONITAUR. Most of the rules added to the current version of 
MONITAUR have the function of filtering spurious symptoms from STAGE2 
input. As was discussed in section 2.7. 1.4, this task remains incomplete and 
would be a major effort in a follow-on project. 

Once the problem of spurious symptoms is solved, the next question to consider 
is enhancement of STAGE2 analysis. The current model based reasoning 
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paradigm utilizes only functional and physical connectivity for fault analysis 
and hypothesis generation and testing. The symptom input mechanism 
currently defined in ADD_SYMPTOM contains sensor behavior information, 
but knowledge of this information is not exploited within DRAPhyS STAGE2. 
An enhancement strategy would be to expand the current paradigm to include 
exploitation of behavioral information to increase the fidelity of the valid 
hypotheses produced. 

One method would be to add behavior to the appropriate data structure for each 
component modeled in each subsystem. Instead of propagating the binary 
condition "abnormal sensor" through the model, agreement between actual 
sensor behavior and modeled behavior would be required for fault propagation. 
We could still retain the binary condition as a default if other search strategies 
fail. A second method would be to incorporate rules from DRAPhyS STAGE 1 
directly into STAGE2. One architecture would have sensor behavior feeding 
inputs into component objects, and part of the component’s behavior would 
derive an output of the condition of that component. An alternative 
architecture would have the component control an output for related sensor 
behavior such that if the component is in a specific state, it would assign 
values to the associated sensors. If we were to adopt this strategy, STAGE1 
would become a testing vehicle for adding new rules. Yet a third method 
would be to model the fault mechanism (i.e., various known ways a device can 
break along with the safety net of "UNKNOWN", which we have now, where 
known modes carry alternate behaviors that can be tested against later data). 
These approaches should be subjected to an alternatives analysis in a follow-on 
project. 

Finally, the anticipated use of context variables for enhanced fault 
identification and for response clarification may also impact STAGE2 
development. Use might be made of context variables to prune the multiple 
fault hypotheses currently generated in STAGE2. This question should be 
addressed in a follow-on project. 
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2.7.3.3 Lessons learned on DRAPhyS STAGE2. 

The most important lesson learned from processing real data in DRAPhyS 
STAGE2 is the unacceptability of spurious symptoms. When healthy engine 
data was processed by MONITAUR and spurious symptoms were passed to 
STAGE2, a host of hypotheses were generated with several being validated as 
faulty sensors. What remains to be investigated is whether sufficient symptom 
conditioning can be performed to render STAGE2 processing usable. At 
present, the current system does not represent a feasible approach to 
processing real engine data. 

2.7.4 Prioritized Suggestions for Further Study 

In view of the progress on all three modules outlined above, the following is the 
recommended development strategy for the follow-on Flight Deck Engine 
Advisor Project. 

Priority 1. 

A maximum effort should be made to eliminate as many spurious symptoms 
as possible from MONITAUR. Only when spurious symptoms have been 
absolutely minimized can we evaluate individual engine differences to 
determine feasibility of real symptom identification. A few of the alternatives 
suggested in the spurious symptom analysis previously sent to NASA have 
been explored with encouraging results, but this list needs to be exhausted. 

Real symptom enhancement needs to be explored, both within MONITAUR 
and in the follow-on diagnosis. The example of actual versus expected "catch- 
up" cited in section 2.7. 1.6 is only one of several potential enhancement 
strategies which may be promoted. Addition of temporal reasoning and ability 
to reason over multiple time slices to either MONITAUR or STAGE 1 (more 
efficiently done in STAGED falls in this category. This will require the 
propagation of historical queue data from MONITAUR to STAGE 1 or the 
reconstruction of this data within STAGE 1. 
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More fault data must be collected to ensure the fidelity of rules generated in 
STAGE 1. Multiple incidences of the same fault and an expanded range of 
faults are both required. To fully evaluate the symptom generation from 
MONITAUR, STAGE 1 development must be maintained in the next iteration. 
Only with a STAGE 1 in place can the identity of unique combinations of 
conditions (and related symptoms) be determined. 

Priority 2. 

The effect of individual engine differences needs to be investigated. This 
should be a follow-on activity to elimination of spurious symptoms, but a 
parallel effort could be undertaken to identify alternatives for dealing with 
individual differences. 

Addition of behavior (in some form) to STAGE2 needs to be addressed as well. 
This could be a follow-on activity to spurious symptom identification, but could 
also be a parallel effort. In either case it would be better to utilize real fault 
data for this task. 


3.0 COMMUNICATIONS 

3.1 Contacts with NASA-Langley Personnel 

3.1.1 Meetings 

Coordination meetings to identify specific content for the Detailed Program 
Plan were held at NASA-Langley, Hampton VA - 4/10/90 to 4/13/90. 
Participants: NASA-Langley - K.H. Abbott, P.C. Schutte; Boeing - W.D. 
Shontz, R.M. Records. 

Project definition presentation and discussions for ATOPS- TRCO held at 
Boeing Commercial Airplane Group, Renton facility - 8/7/90. Participants: 
NASA-Langley - Cary Spitzer; Boeing - Ralph Erwin, Bill Shontz, Mary 
Hornsby. 
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Presentation on project progress and discussion of potential follow-on topics 
held at Boeing, Renton facility - 9/26/90 and 9/27/90. Participants: NASA- 
Langley - K.H. Abbott, P.C. Schutte; Boeing - W.D. Shontz, R.M. Records, J.G. 
Lutch. 

Presentation of Oral Interim Report followed by discussions with NASA, BB & 
N, and Boeing personnel held at NASA-Langley, Hampton, VA - 11/27/90 and 
11/28/90. Participants: NASA-Langley - K.H. Abbott, P.C. Schutte; BB & N - 
W.H. Rogers; Boeing - W.D. Shontz, G.P. Boucek. 

Coordination meetings to discuss issues affecting follow on to the current 
project and to clarify details of follow on activity which would be acceptable to 
NASA were held at NASA-Langley, Hampton, VA - 2/28/91 and 3/1/91. 
Participants: NASA-Langley - K.H. Abbott, P.C. Schutte; Boeing - W.D. 
Shontz. Also coordinated Flight Deck Engine Advisor activities on pilot 
information requirements with W.H. Rogers of BB & N. 

Attended meeting and made presentation on the Flight Deck Engine Advisor 
project at the GE installation at Evensdale, OH - 3/20/91. Participants: NASA- 
Langley - K.H. Abbott; Boeing - W.D. Shontz; GE - Dave Doel, et al 

3.1.2 Telenhone Consultations 

Clarification of specific project activities as described in the Detailed Program 
Plan - 5/6/90 and 5/9/90. Participants: NASA-Langley - Paul Schutte; Boeing - 
Roger Records, Bill Shontz. 

Discussion of revision to the Detailed Program Plan suggested by Kathy Abbott 
- 6/1/90. Participants: NASA-Langley - Kathy Abbott; Boeing - Bill Shontz. 

Further discussion of proprietary issues and current status with respect to 
being able to deliver an engine model and real engine data - 6/18/90. 
Participants: NASA-Langley - Kathy Abbott; Boeing - Bill Shontz. 

Phone consultations with BB & N subcontractor to NASA-Langley to coordinate 
BB & N and Boeing efforts on pilot information requirements as they relate to 
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work both companies are doing for NASA-Langley on the Faultfinder concept. 
Several phone calls oyer the course of the project. Participants: BB & N - W.H. 
Rogers; Boeing - W.D. Shontz. 


Phone consultations on project progress, direction, and trip planning. 
Numerous phone calls over the course of the project on technical issues, status 
and content of follow on SOW, status of resolution of proprietary data issues, 
coordination of trips and meetings. Participants: NASA-Langley - Kathy 
Abbott, Paul Schutte; Boeing - Bill Shontz, Roger Records. 

3.2 Contacts with Engine Manufacturers 

3.2.1 Pratt & Whitnev 

Person Contacted: BillStepule (203)565-9371 

Contacted by: Bill Shontz 

Data of Contact: 8/9/90 

Summary of Information Obtained: 

Mr. Stepule is in a diagnostics group where they evaluate flight data, program 
ACMS, and have developed ground based software for monitoring engine 
performance at the module level. The PW engine condition monitoring 
program is called Turbine Engine Aids Monitoring (TEAM 3). 

We discussed at some length the kind of monitoring and control activity that 
occurs in the engine controller on new engines. We also discussed PW's 
engine condition monitoring program with the airlines. I will have more 
comments on these areas in a general summary at the end of this section. In 
general, Stepule indicated PW was interested in the type of engine monitoring 
represented by the Engine Advisor project but that they lacked the time to 
investigate it more thoroughly at present. 
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3.2.2 


Person contacted: MikeBarwell (011)44-332-249505 

Contacted by: Bill Shontz 

Date of Contact: 8/23/9(5 

Summary of Information Obtained: 

Each of the engine manufacturers contacted has a software program for 
monitoring engine condition. The Rolls Royce system is call COMPASS - 
Condition Monitoring and Performance Analysis Software System. COMPASS 
is said to have an engine model embedded in it. However, the nature of this 
model is not entirely clear from the written material Mr. Barwell referred me 
to (Ref 7) and he did not elaborate beyond the information contained in the 
paper. The frame of reference I gave in introducing myself was our interest in 
airborne engine model/monitoring systems to provide diagnostic and trend 
information on engine performance on the flight deck. Mike indicated that RR 
was not doing anything at the moment that would convert COMPASS to an 
airborne system. However, the COMPASS features of deviation detection and 
trend analysis are certainly capabilities which an airborne system should 
have. 

3.2.3 General Electric 

Persons Contacted: Neal Walker - 8/23/90 - (513)774-6083 

Jim Elliot - 9/11/90 - (513)774-6143 
Kiyoung Chung - 9/11/90 - (513)583-5401 
Dave Doel - 9/11/90 - (513)583-5469 
Hal Brown - 9/13/90 - (513)583-5441 
George Converse - 9/17/90 - (513)583-5466 
Ron Plybon - 10/4/90 - (513)583-5472 

% 

Contacted by: Bill Shontz 

Dates of Contact: Between 8/23/90 and 10/4/90 
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Summary of Information Obtained: 

My contacts with Walker, Elliott, and Chung served to identify additional 
people within GE with whom I should talk. In fact, each person in the list 
above referred me to the next person as one I should really talk with. The 
conversations with Doel, Brown, Converse, and Plybon were all of a technical 
nature and with increasing level of specific technical details. Of these 
contacts, Dave Doel will probably be the primary focal point for further contacts 
with GE for two reasons. One, he is familiar with the Faultfinder concepts via 
having read paper presentations of Abbott, et al at NASA-Langley and will be 
the GE focal point for contact with NASA-Langley. Two, Ron Plybon referred 
me back to Dave at the end of our conversation on 10/4/90. 

As with the other two engine manufacturers, GE is focusing primarily on 
ground based engine condition monitoring for maintenance (they call their 
system GEM). However, there appears to be a great deal of activity in engine 
monitoring and control which would be relevant to the development of a flight 
deck engine advisor system. Further, one of Dave Doel's charges appears to be 
to keep up with developments of flight deck engine advisor concepts. Hal 
Brown indicated GE has done some work towards fault detection on civilian 
engines; they have done much more on military contracts - particularly the 
Pilot's Associate program. He also indicated they will be doing more in the 
future. 

Of particular interest was the concept of "hard and soft failures" discussed by 
both Brown and Plybon. Hard failures are those that occur over a relatively 
short time span and are relatively easy to detect and diagnose. Soft failures, on 
the other hand, are the result of slow degradation in part or component 
performance and are very difficult to detect and diagnose. It is in detecting 
and diagnosing these latter types of failures that the Faultfinder concept could 
have a major impact. 

3.2.4 General Summary of First Half Contacts 

All engine manufacturers surveyed have developed major software packages 
for engine condition monitoring to support maintenance planning activities. 
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However, interest in the Faultfinder concept of monitoring and diagnosis 
varied considerably. It is not known whether this represents genuine 
differences in levels of interest within companies or different levels of concern 
for proprietary issues among individuals I talked with. 

It also became clear, that there is considerable monitoring going on in new 
electronic engine controllers that is of the type that would be directly applicable 
to the Engine Advisor concepts. Further, the continual addition of parameters 
that are sensed suggests the possibility of much more sophisticated trend 
monitoring and fault prediction than has been possible in the past. The weak 
links to date in developing engine monitoring and fault diagnosis systems 
which provide information to the flight deck is the availability of sophisticated 
and reliable real-time engine models. These models must have stable, 
narrowly defined bands for normal parameter performance yet be adaptable to 
the variations across engines of the same type. A second weakness is the lack 
of a well organized, structured data base readily available for engine model 
and monitoring and diagnosis module development. The engine performance 
data base being accrued by the major airlines along with Boeing flight test data 
and engine manufacturer data may serve as a starting point for data base 
development. 

A second round of contacts with Key individuals at each company will be 
initiated during the second half of the contract. 

3.3 Second Half Contacts with Eng ine T yfanufon tiirers 

3.3.1 Pratt & Whitnev 

Persons Contacted: Rick LaPrad - 1729/91 - (203)565-6883 

Bill Stepule - 2/11/91 

Dick Meisner - 4711791 - (203)565-3842 

Bill Gallops - 5/13/91 - (407)796-2172 

Contacted by: Bill Shontz 

Dates of Contact: Between 1/29/91 and 5/13/91 
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Summary of Information Obtained: 

The contact with Rick LaPrad served only as reference back to Bill Stepule who 
was contacted early in the current project. The discussion with Stepule 
focused on his work in performance monitoring. It appears, based on 
discussions of performance monitoring work with the engine manufacturers, 
that the airlines may be the best source of fault data acquired in an operational 
environment. Stepule also referred me to Dick Meisner at Hartford. Meisner 
in turn referred me to Bill Gallops of PW's newly renamed Government 
Engines and Space Propulsion Division (formerly the Government Products 
Division) in West Palm Beach. It was with the Gallops contact that I was at 
last talkin g with the right person at Pratt & Whitney. As with GE, PW s work 
on engine modelling has been largely supported by military programs. Both 
PW and GE have approaches to adaptive engine modelling which are similar 
in some ways but quite different in others. It remains to be seen which 
approach would best support the monitoring function within the Flight Deck 
Engine Advisor system. The proprietary issues surrounding transfer of 
engine model code and engine data was raised with Gallops. He indicated he 
would try to contact people in the commercial group at Hartford regarding the 
issue. He also suggested that perhaps an industry group such as an SAE 
co mmi ttee should be formed to coordinate efforts in engine modelling so that 
people retain an appropriate focus. 

Contact will be maintained with PW through Bill Gallops. He knows Dave 
Doel of GE and they appear to be comparable contacts at the two engine 
manufacturers. 

3.3.2 Rolls Rovce 

Person Contacted: Dennis Burnell - (Oil) 44-332-247922 

Contacted by: Bill Shontz 

Date Contacted: 1/29/91 
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Summary of Information Obtained: 

Dennis Burnell is in the Advanced Controls group of RR Bristol. He was an 
appropriate person to be talking with but as in the earlier conversation with 
Mike Burwell very little information was gained about what RR may be doing 
that is related to the current contract. No further contact is planned with Rolls 
Royce. 

3.3.3 General Electric 

Persons Contacted: Dave Doel, fit fd 

Contacted by: Bill Shontz 

Date(s) Contacted: Doel phone calls re meeting at Evensdale 3/20/91 - 

meeting at Evensdale, OH 

Summary of Information Obtained: 

The meeting at GE in Evensdale, OH consisted of a number of presentations by 
GE people describing work they have undertaken which they felt relevant to the 
fault management program efforts being sponsored by NASA-Langley. 
Speakers included: 

Dave Doel - GEAE 
Kathy Abbott - NASA-Langley 
Bill Shontz - Boeing 
Hal Brown - GEAE 

Dick Dyson - GEAE (phone number not available) 

Bruce Pomeroy - GE CR & D (phone number not available) 

Pete McDonald - GEAE (phone number not available) 

Presentations were followed by a discussion of issues of common interest to the 
group. Included in this discussion was the potential for NASA obtaining an 
engine model from GE. There was no one present who could really address 
the issue. 
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3.3.4 General Summary of 2nd Half Contacts 

It appears that both GE and PW have some activity under way directed at 
developing the kind(s) of engine model(s) needed to support a flight deck engine 
advisor system. The approaches appear to be similar in some ways and very 
different in others. The information available at this time is insufficient to 
permit any judgement on the feasibility of the approaches. Such a judgement 
should be made, however, before tying the development of the Might Deck 
Engine Advisor system to a particular approach. 


4.0 RESULTS AND CONCLUSIONS 
41 Hardware and Software Selection 

The selection of a PC environment using GCLISP and CLOE for enhancement 
of Faultfinder has provided additional flexibility for the research process. We 
were able to modify MONTTAUR to accept real fault data in a batch mode and 
integrate the associated engine model data files. The GCLISP environment, 
while not as elegant as Genera LISP, still proved adequate to accommodate the 
revisions implemented to reduce spurious symptom generation in 
MONITAUR and fault-symptom association in STAGE1 of DRAPhyS. The 
CLOE implementation was, in like manner, adequate for testing the through 
put of real fault data in STAGE2 of DRAPhyS. 

We recommend the continued use of both PC development environments for a 
follow on project. Should NASA choose to disseminate our enhanced versions 
of MONITAUR, STAGE 1 and STAGE2, they will find the engineering 
community at large has a much larger PC base than LISP workstations. 

4.2 Fault Scenario Selection and Development 

4.2.1 Selection 

The selection process involved selection of an engine model to be used in the 
enhancement process and candidate faults to be used in the information 
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requirements analysis and knowledge base development. Engine model 
selection was quite straight forward once available models were identified. 
Propulsion simulation experts familiar with the strengths and weaknesses of 
the various models evaluated each model on the basis of criteria developed by 
Boeing and NASA. The model selected had clear advantages over competing 
models. The details of this process are described in Section 2.4.1. Proprietary 
issues have precluded inclusion of the modelled engine's identity and code in 
the Final Report. Efforts to permit inclusion of an engine model and engine 
data as a part of the deliverables in any future work on Flight Deck Engine 
Advisor are being carried out as a part of the follow on proposal process. 

Fault candidate selection was driven by two factors; availability of real engine 
data, and the match between fault data characteristics and the criteria for 
selection developed by NASA and Boeing. Of these two, availability was the key 
factor. Eventually we were able to acquire data on eight faults which, taken 
together, provided coverage of all nine criteria established. The process of 
selecting faults continued over a much longer period during the contract than 
had originally been planned because of the nature of the process of identifying 
potential faults and locating and preparing the engine data for analysis. The 
identity of faults and location of the data resided in the memory of engineers 
who had worked with the data rather than being available through a readily 
accessible cataloging system. Rather than arbitrarily terminate the search for 
additional fault data early in the contract, we elected to leave the possibility of 
acquiring additional data open as long as possible. This did not delay work on 
knowledge base development and allowed us to devote more time to the details 
of fault scenario development than would have otherwise been possible. The 
result was an iterative approach to fault scenario and knowledge base 
development which allowed us to complete more fault scenarios than would 
have been possible under the original schedule. 

4.2.2 Development 

Fault scenarios were developed to serve as the data base for knowledge base 
development. They are the repository of data on the fault propagation sequence 
and symptoms. Because the pilot information requirements were in fact an 
integral part of data needed for knowledge base development, information 
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requirements analysis was carried out as a part of scenario development. The 
information requirements analysis and related conceptual development are 
discussed separately below. A complete version of each fault scenario is 
contained in Appendix A. The overall concepts developed and definitions of the 
various entries in the scenarios 'are contained in Section 2.5. 

The process of developing data on fault propagation, symptoms, and 
information requirements for fault diagnosis represented the knowledge 
engineering phase of knowledge base development. The experts involved in 
this process were propulsion simulation experts and research pilots. Fault 
candidates were identified and engine data acquired by the propulsion experts. 
Preliminary guidance on fault propagation sequence and symptoms was also 
provided. From this, the fault scenario contents were developed. Propulsion 
experts and pilots then reviewed the contents for accuracy, clarity, and 
completeness. Additional potential fault alternatives were typically identified 
at this stage. When a fault scenario had completed this process it was turned 
over to the knowledge base developers. Any modifications to the scenario data 
base required to enhance its use in knowledge base development were also 
made. The result is a well coordinated and integrated data base for knowledge 
base development and a starting point for future analyses of pilot information 
requirements. 

While the fault data base used in the present study was adequate to support 
initial enhancement activities on the MONITAUR and DRAPhyS modules, 
additional data will be required for further development of the DRAPhyS 
modules and feasibility testing of MONITAUR. Some additional fault data will 
be available from flight test files but efforts to identify and expand the data base 
through engine manufacturers and airlines are proposed as a part of follow on 
work. 

4.3 Pilot Information Requirements 

The information requirements analysis conducted as a part of fault scenario 
development focused on information required to diagnose faults without 
concern for whether the diagnostic process was carried out by humans or 
computers. This approach was necessary to provide the data needed for 
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knowledge base development. It may be contrasted with higher level analyses 
of pilot information requirements in fault management being supported by 
NASA through other contractors. As a part of the analysis conducted on the 
current project, information now available to pilots was identified as well as 
the information required for diagnosis. The criticality of any discrepancies 
defined is a function of the level of diagnosis the pilot must go to in order to 
select the optimal action alternative. This in turn will be affected by the level of 
automation present in the system(s) in which the fault propagates and the 
ability of the automation to control fault management. An issue which needs a 
good deal of further investigation is impact of state-of-the-art automation in 
airplane systems on fault management problems. This issue would be 
addressed in a Context Analysis task proposed for follow on work. 

An important aspect of the information requirements work on the present 
contract was the development of a conceptual framework for addressing the 
event/fault/context/action relationships involved in fault management. The 
relationships are complex but analysis could also indicate ways to simplify the 
problems in fault management while allowing pilots to deal with faults more 
selectively than they now can. Allowing pilots to deal with more complexity 
while simplifying the decision process would, of course, require the support of 
a Flight Deck Engine Advisor system. Details of the conceptual framework are 
to be found in Section 2.5.3. The feasibility and efficacy of the concepts would be 
tested in the Context Analysis proposed for follow on work. 

A number of issues related to information requirements are discussed within 
the context of specific fault scenarios. This is as it should be because the issues 
are context specific. However, the issues which generalize are: 

- granularity of the data (which includes sensor resolution); and 

- reliability and validity of parameter data for fault diagnosis and action 
recommendations. 

Generally speaking, the engine parameter data available from flight tests is 
based on sensors which have much greater resolution (i.e., are much more 
sensitive) than sensors available on operational engines. Further, more 
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sensors are installed for flight testing; hence more parameters are measured. 
These sensors also happen to be too fragile for the operational environment. 
Probes would break off and create their own faults. Thus it is possible, with 
the test flight data, to see the potential for detecting the adverse trends of fault 
propagation much earlier and with more precision than may be possible with 
data from operational sensors. The issue is not simply the presence or absence 
of sensors. In some cases, the parameters are sensed and the information 
used by the electronic engine controller but is not currently available to 
systems which co mmuni cate with the flight deck. In other cases, the 
availability of sensors is an option to the airline purchasing the engine. 
Therefore, it is appropriate to base our analyses on what may be available 
operationally as well as what is. 

The reliability and validity issue relates to the fact that our current data base 
does not contain enough samples of same event caused by same fault or same 
event caused by different fault. These additional fault data samples are needed 
to test the effectiveness of the Flight Deck Engine Advisor modules in detecting 
and diagnosing faults across engines and event/fault combinations. These 
issues would be addressed as a part of the Engine Data Survey task proposed as 
a part of a follow on effort. 

4.4 Knowledge Base Development 

As real engine data for known faults were processed through MONITAUR for 
symptom identification, the problem of spurious symptoms became apparent. 
When healthy engine data was passed through the system, the extent of 
spurious symptom generation was found to be present in excess of 50% of the 
time slices. Analysis revealed several potential causes and initial efforts to 
reduce spurious symptoms have been quite successful.. The current level for 
healthy engine data stands at between 20-30% of the time slices, a value still too 
high for operational integrity. We have identified several additional strategies 
for further reducing spurious symptoms which should be pursued in a follow 
on project. 

As a result of our work on symptom generation, NASA .agreed to a reduction 
in effort on knowledge base development. We have done significant 
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development in associational fault identification in STAGE 1 of DRAPhyS. Our 
investigation with real fault data has produced a strategy for knowledge 
acquisition that includes traditional expert interviews coupled with a data 
verifying technique using a matrix format for symptom analysis. As this 
process is refined, it can probably be automated. More fault data is needed for 
a follow on project - especially multiple occurrences of the same fault, as well 
as a broader spectrum of faults. 

Our work with STAGE2, the model based reasoning component of DRAPhyS, 
has been primarily familiarization and conversion to a PC environment. We 
have analyzed the current model based implementation and have made 
recommendations for potential enhancement by identifying several 
alternatives for incorporating sensor behavior into the system. We are 
confident that any of the alternatives will improve the fidelity of the hypotheses 
generated by the model based system. One of the alternatives would allow a 
merger of STAGE 1 and STAGE2 forming a hybrid capable of both robust 
behavior and fault association. 


5.0 RECOMMENDATIONS 

Based on lessons learned in conducting the current project, the following 
recommendations are made as reasonable and appropriate next steps in follow 
on work for the Flight Deck Engine Advisor program. 

5.1 Stand Alone MONITAUR 

There are three areas of improvement which should be developed for a 
demonstration of MONITAUR feasibility. First, spurious symptoms must be 
eliminated, or at least minimized to an acceptable level. Next, steps must be 
taken to insure that valid symptoms are retained in the process of eliminating 
spurious symptoms. Finally, valid symptoms must be enhanced to promote 
successful diagnosis. 
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5.1.1 Spurious Symptom Elimination 

A primary goal of a follow on project must be to minimize the number of 
spurious symptoms generated from MONITAUR. During the present 
investigation we have identified multiple sources of spurious symptoms and 
have significantly reduced the initial volume. Additional alternatives have 
also been identified and must be developed. We anticipate that other sources of 
small numbers of spurious symptoms can yet be determined. This should be a 
priority in the next project. 

To insure a true minimum of spurious symptoms, more fault data must be 
collected. To verify the generality of current symptom-fault association, 
multiple instances of the same fault should be used. To verify that a broad 
spectrum of spurious symptoms have been filtered, more individual faults 
need to be analyzed. 

5.1.2 Valid Symptom Retention 

A possible consequence of spurious symptom filtering is the loss of valid 
symptoms. Great care must be taken to avoid the loss of valid symptoms while 
eliminating spurious symptoms. A method of evaluating the quality of valid 
symptoms is needed. Validating the existence of all anticipated symptoms for 
known faults is one approach to safeguarding valid symptom generation. We 
recommend a minimal STAGE 1 development as a MONITAUR evaluation 
tool. The secondary effect of constructing a STAGE 1 knowledge base with 
enhanced fault identification will be of mutual benefit to both NASA and 
Boeing. 

5.1.3 Valid Symptom Enhancement 

The last category of work for MONITAUR is valid symptom enhancement. 
Boeing has identified two strategies for enhancing the fidelity of valid 
symptoms generated by MONITAUR - Use of context variables and use of 
symptom type. 
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The effect of context variables is discussed in section 5.3, but provision for 
incorporating knowledge about context variables needs to be made in 
MONITAUR. Symptom enhancement may take the form of symptom 
elimination, symptom addition, or symptom modification. An example is the 
phase of flight. During our current study, a pattern of symptoms for ground 
hung start was found similar to a pattern for heavy ice damage. A simple 
addition of phase of flight would have enhanced this symptom pattern enough 
to be unique. 

The analysis of symptom development with real fault data has shown that not 
all symptoms have the same severity. The case of sensor "catch up" described 
in section 2.7. 1.6, when the actual value of a sensor was approaching, but not 
quite close enough to, the expected value, is a good example. Categorization of 
symptom severity offers potential for valid symptom enhancement and should 
be developed in the follow on project. 

5.2 Engine Fault Data Base Survey 

The current data base on engine faults is inadequate to support feasibility 
testing of the expert system based modules for fault detection and diagnosis. 
The nature and extent of a relevant data base made up of real in-flight engine 
fault data is unknown at this time. Indications are that the necessary data 
base will need to be assembled from a number of sources - primarily airlines 
and engine manufacturers. It is recommended that a survey of potential data 
base sources be made to determine: a) the nature of the data available; b) 
problems in accessing the data; c) proprietary issues to be dealt with; and d) 
data format problems. Additional fault data is also available from the Boeing 
flight test data base although the extent of this data is limited. The fault 
scenario data base should be expanded using flight test data plus any fault 
data which may become available as a result of the data base survey activities. 
An expanded fault scenario data base would be used in the development and 
testing of a stand alone MONITAUR. 
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5.3 Context Impact Analysis 

Context variables can have a major impact on action alternatives available to 
the crew for any given fault/ event combination. A framework for 
conceptualizing the event/fault/context/action (E/F/C/A) relationship was 
developed during the present contract. A systematic understanding of these 
relationships across fault/event combinations when different context variables 
are present or absent could be used to evaluate the viability of crew action 
alternatives. This information could in turn be used to develop rules for the 
knowledge base which fine tune the diagnostic process within the Flight Deck 
Engine Advisor system. It is recommended that a systematic analysis be 
carried out to assess the impact of context variable status on specific 
fault/event combinations. Particular attention should be given to those 
circumstances where context variable status might turn a viable crew action 
alternative into a potentially unsafe action. The analysis should be conducted 
within the context of a state-of-the-art glass cockpit airplane so as to provide 
the greatest relevance to future flight deck systems. 

5.4 Automation in Fault Management 

If the Faultfinder concept is to be relevant to advanced technology airplanes, 
the impact of automation on current and anticipated engine fault 
management function allocation decisions must be fully understood. It is 
recommended that an effort be undertaken to inventory the allocation of fault 
management functions which has been implemented for state-of-the-art 
commercial transport airplanes and critique the impact of this allocation 
pattern on pilot situational awareness and crew fault management options. 
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FLIGHT DECK ENGINE ADVISOR 
FAULT SCENARIO - FI 

Event : Hung Start - Ground 

Eailli: Fuel metering unit malfunction - providing too little fuel to fuel nozzles 

Potential Fault Alternatives 

Pneumatic System Faults 

- Pneumatic pressure too low 

- Airplane pneumatic duct failure 

- Starter air valve failure 

duct failure 

- Starter failure (partial failure results in too 
little air flow/pressure 

Fuel System Faults 

- Fuel metering unit 

- Fuel shutoff valve 

- Engine fuel pump 

- fuel boost pump (high altitude air starts) 

- Engine fuel line 

- Mismanaged fuel system configuration 



Start Procedure Faults 

- Attempt start with excessive tail wind 

- Airplane pneumatic system improperly configured 

- Too cold: failure to use RICH; improper selection of 

fuel; too cold even for RICH 

- Outside of start envelope 

- improper fuel 

- Fuel pressurization when high rotor speed too low 

Gas Generator Faults (Compressor/Turbine) 

- Bleed valve failure 

- Stator vanes off schedule (mechanical failure or 

misrigging 

- Compressor damage 

- Turbine damage 

- Low speed rotor locked (stuck) 

Engine Control Faults 

- Sensor fault 

- Software error 

- Hardware failure 

- Actuator failure 

- Engine wiring (e.g., intermittent broken connection between engine 

controller and fuel metering unit) 

Relevant Context Var iables - Status 
Phase of Flight - Ground start 

Weather - Clear and dry; light crosswind; temp 50 deg F 
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FARs - 


Engine Fault History - no persistent, related problems for engine or type 
Airline Policy - 

Engine Commanded Status - Start 
Pilot Error - None 

Airplane System Status - Right Pack Inoperative 
Workload - Moderate 

Action Alternatives 

Shut down and secure engine 

Execute shutdown/restart procedures 

Shutdown engine, correct fault, and execute restart procedures 

Subsystems Affected 
Engine 

Electrical, hydraulic and pneumatic power from affected engine would not be 
available, but this information plays no role in fault diagnosis. 


Propagat ion Sequence with Rank Order Time Base 

Time t - Fuel metering valve commanded to start position by electronic 
control. 

Time tl - Valve moves to a partially open position and sticks OR fails to 
move from minimum open position. 

Time t2 - Fuel going into burner not sufficient to support normal spool up of 
engine to idle. 

Time t3 - FF begins to drop below flow rate for normal start. 

High rotor speed acceleration rate begins to lag behind normal 
rate. 

Low rotor speed still appears normal at this point. 
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Time t4 - 


Time tS - 


Time t6 - 


Time t7 - 


EGT increase rqte normal. 

High rotor speed still increasing but has only reached 75% of 
normal for time into start sequence. 

FF increasing but has only reached 70% of normal. 

Low rotor speed levelled off at 53% of normal. 

EGT still appears to be increasing at approximate normal rate. 
High rotor speed still increasing but rate of increase falling off. 
Should be at idle RPM at this point but only at 67% of idle RPM. 

FF fluctuating (probably not visible on cockpit gauge) and still 
increasing slowly; should be stable at this point. 

Low rotor speed very slow increase, 41% below normal. 

EGT rate of increase right on normal for time into start sequence. 
High rotor speed, FF, low rotor speed all 40-70% below normal. 
EGT continuing to increase instead of levelling off; 13% above 
normal and rising. 

High rotor speed, FF, and low rotor speed leveling off below 
normal. High rotor speed peaks at 49% and begins sharp decline 
following starter disengage. Low rotor speed begins to decline a 
few seconds later. 

EGT continues to rise at same rate and is approaching start red 
line (hot start conditions developing). 


Time t8 - Fuel cutoff switch closed. 


Data Pilots Have Available 
Source of Data : 

EICAS Engine Instruments 
Engine Start Panel 
Explanation of Relationships : 


Pilots use high rotor speed to indicate appropriate time to turn fuel ON then go 
by the "clock" (real time monitored or estimated) to determine if "light off' has 
occurred normally. Once light off has occurred, they monitor high rotor speed 
and EGT to determine if a start is progressing normally. Fuel Flow (FF), EGT, 
and low rotor speed also have appropriate rates of increase during a normal 
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start; however, the rate of change for each parameter will be different. If a 
normal start is not achieved, high rotor speed will begin to decline if a 50% 
speed has been achieved and the starter disengages. When starters disengage, 
starter switches snap to the GRND or OFF position. This produces an audible 
click which is a cue for starter disengage in addition to a visual check of the 
switch position. 

Quality of Data: 

Fuel flow data is processed and smoothed before being presented on the EICAS 
display. Thus the fine grain data on this parameter which can be used for 
early detection of a hung start due to fuel metering problems is not available in 
the cockpit in a easily detectable form. 

Heuristics or Rules of Thumb Used : 

The typical high rotor speed/EGT relationship looked for is high rotor speed X 
10 = EGT. Since the critical factor is avoiding a hot start, more attention is 
probably paid to EGT than anything else. In the type of fault leading to a hung 
start presented in this scenario, focusing attention on EGT can lead to delayed 
detection of the hung start condition. EGT continues to increase at a close to 
normal rate long after definite symptoms of a hung start are apparent in other 
parameters. 

Time Constraints : 

Light off normally occurs within 10 seconds after fuel ON. Stable parameter 
readings at idle should be achieved at approximately time t5. Hot start 
indications become apparent very rapidly once conditions are right. Pilots will 
have only a few seconds at most to recognize them and shut off fuel to the 
engine before an overtemp condition develops. 
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Comments : 


If the data used in this fault scenario is typical, then hung starts are difficult 
for pilots to detect until either a) a long time has passed (well over a minute), or 
b) the hot start phase begins arid EGT rapidly heads for the "start" red line. 

Information Required to Make Diagnosis 
Kev Parameters : 

Fuel Flow 

High Rotor Speed 

EGT 

Low Rotor Speed 
Symptoms : 

At time t3: 

Marked departure of fuel flow from normal rate of increase. 

Small deviation in rate of change in High Rotor Speed. 

Low Rotor Speed rate of increase normal. 

EGT rate of increase normal. 

At time t4: 

High Rotor Speed still increasing but with marked deviation from 
normal in rate. 

Fuel flow increasing but far below normal rate. 

Low rotor speed essentially levelled off, should be increasing rapidly. 
EGT increasing at normal rate. 

Fuel flow and high and low rotor speed continue to increase at decreasing 
rates until starter cutout at t7. At that point, high rotor speed begins to decline 
sharply followed by declining low rotor speed. EGT continues to increase at a 
normal rate until t5. Beyond t5, EGT continues to increase at the same rate 
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instead of leveling off as it should. This leads to the hot start phase of the hung 
start. 

Interpretation : 

In general, detecting a hung start in progress requires the detection of 
deviations from normal in the rates of change on the four parameters listed 
above; i.e., detecting changes in the rates of change 1 . The symptoms for 
detecting the onset of a hung start caused by a fault in the fuel metering 
system present a particular challenge to pilots because the parameter showing 
the earliest departure from normal is fuel flow (see time t3 above). The change 
in the rate of change in high rotor speed has also begun to take place by t3 but 
would be difficult to detect in the cockpit at this point. Adding to the detection 
problem is the fact that low rotor speed and EGT are progressing normally at 
this point. By t4, FF and High and Low Rotor Speeds clearly indicate a hung 
start in progress but EGT is progressing normally. The problem, from a 
pilot's perspective, is; a) determining that a hung start is in progress, while b) 
seeing that high rotor speed is still increasing at a rate which is not perceptibly 
different from normal but knowing that at that point it is in fact 15% low, and 
c) all the while seeing EGT progress normally. The data available from 
sensors is not available to the crew at the same grain on the EICAS as it shown 
on sensor data printouts. And even if it were, the complexity of the monitoring 
and deviation detection process required for early detection of a b ung start is 
clearly beyond the capability of the crew. Hence the start scenario heuristic 
reported above which pilots use to monitor engine starts. This heuristic 
inevitably leads to much later recognition of the event in progress and much 
higher probability of an over temp condition occurring. This particular 
scenario is a case in point. EGT continued to progress normally long after the 
hung start condition was obvious in the pattern of the other three engine 
parameters. Engine shut down was not initiated until much later when a hot 
start was in progress. 

There are two objectives of diagnosis in an event such as hung start. The first 
objective must be to provide an alert to the crew that the event is in progress; 

1 MONITAUR does not now contain a parameter for processing changes in rates of change. 
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i.e., a normal start is not in progress. This requires evaluation of information 
about changes in rates of change on four parameters (high and low rotor 
speeds, FF, EGT). By comparing this information with the output from an 
engine model, it is possible to diagnose a developing hung start less than half 
way into the start sequence. 

The second objective is to diagnose to the fault or Fault/Action Class. This may 
be taken to the subsystem (e.g., fuel pneumatic, procedural, etc.) or component 
level (fuel metering) within the propulsion system. Here the purpose is to 
provide part of the basis for determining relevant action alternatives. The 
Hung Start-Ground data plot on fuel flow shows a marked deviation from 
normal before mid point in the start sequence (t3). This may be sufficient to 
narrow the location of the fault to the fuel subsystem. While it may not be 
possible to differentiate among all potential fault alternatives within the fuel 
subsystem, it may be possible to distinguish between subclasses. The 
importance of such distinctions will depend on their impact on action 
alternatives. 

Information Required for Decision Aiding 
Nature of the Fault : 

Selection of or recommendations on the appropriate action alternative requires 
knowledge of the nature of the fault or fault/action class. The components of 
that knowledge are: 1) a hung start is in progress; 2) the engine is not 
receiving the appropriate fuel/air mixture; and 3) whether electrical, 
mechanical, or procedural subsystems are involved. The actions required by 
pilots in dealing with the fault generally will differ only if the fault is 
procedural vs. electrical or mechanical. 

The data for this fault scenario is based on a mechanical failure. It is a 
malfunctioning valve in the fuel metering system. It is not a transitory 
failure. The corrective action must be taken by Maintenance. 
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Relevant Context Variable Set : 

Phase of Flight 
Weather 

Engine Fault History 
Engine Commanded Status 
Pilot Error 

Airplane System Status 
Workload 

Relat ionship Between Fault and Context Variables for : 

Diagnostic Application - Because phase of flight is "ground start", all those 
potential fault alternatives peculiar to air starts can be eliminated from 
further consideration. The value of the weather variable would serve to 
eliminate the possibility of gusts up the tail pipe and temperature too cold as 
potential faults. Improper fuel, pneumatic system configuration, and 
premature fuel ON during start sequence cannot be eliminated. These 
procedural faults need crew and/or maintenance input to eliminate. For the 
particular context variable set chosen, no history values will aid in diagnosing 
the fault. The system status item is not relevant as a direct contributor but 
would have influenced pneumatic system configuration. The workload 
variable operates in conjunction with other variables to produce an effect. It 
can operate with other context variables or with certain fault categories, 
namely procedural faults. Beyond this point, diagnosis must rely on the 
propagation sequence and pattern of symptoms. 

Action Alternatives Application - The application here is very straightforward. 
Given the context variable set plus the fact that diagnosis has been made to the 
component level (fuel metering unit), there is only one appropriate action. The 
Shutdown, correct fault, and execute restart procedures" is not appropriate 
because the pilots can not carry out the corrective action. 


Recommended Action Alternative - Shut down and secure engine. 
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FLIGHT DECK ENGINE ADVISOR 
FAULT SCENARIO - F2 


Event : Engine Flameout 

Fault : Fuel Boost Pump failure - due to A/C power loss 

Potential Fault Alternatives 

Loss of both boost pumps in same tank 

Engine fuel pump failure 

Mismanaged fuel configuration 

Fuel line fracture 

Relevant Context Variables - Status 

Phase of Flight - Cruise: above fuel suction feed altitude 

Weather - 

FARs - 

Engine Fault History - 
Airline Policy - 

Engine Commanded Status - Steady state 
Airplane Systems Status - Crossfeed valves closed 
Fuel Type - 
Workload - Light 

Action Alternatives 

Recycle generator and bus tie switches 

Reconfigure fuel system 

Reduce altitude to suction feed level 
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Subsystems Affected 
Fuel Delivery 
Engine 

AC electrical (a failure malfunction in this subsystem would produce the same 
event. Some or all of the action alternatives might be the same as those 
identified above.) 

Propagation Sequence with Rank Order Time Base 


(The same propagation sequence within the engine would occur if AC power 
were lost to the fuel boost pump.) 


Time t- 

Time tl - 
Time t2 - 


Time t3 - 


Time t4 - 


Time t5 - 


All subsystem operation and parameter values normal for 
conditions of flight 
Fuel boost pump fails. 

A 25# (approx.) step drop occurs in fuel pressure. This is not 
enough to trip fuel pressure switch light or EICAS message 
circuits. No change occurs in fuel flow. High or Low Rotor 
Speeds. 

Fuel pressure shows only slight further decline over approx 
quarter of a minute. No change in other engine parameters. 

Fuel pressure drops precipitously to near zero. Fuel flow drops to 
near zero (this indication should be clearly visible in the cockpit). 
High and low rotor speeds begin to drop off gradually. Fuel 
pressure switch light and EICAS message circuits would be 
tripped by this drop. 

Fuel pressure has levelled off at approx 25#. Fuel flow is at zero. 
High rotor speed is slipping into sub-idle. 
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Data Pilots Have Available 
Sources of Data : 


A/C Electrical Control Panel 

Fuel Control Panel 

Altimeter 

EICAS Messages 

EICAS Engine Instruments 

Explanation of Relationships : 

The amber PRESS light within the fuel boost pump switch illuminates if pump 
output pressure drops below 5-7 lbs. for 10 seconds for any reason. Thus with 
an A/C power loss, lights on both the A/C Control Panel and the Fuel Control 
Panel would come on. EICAS messages would appear for both the A/C power 
loss and the boost pump pressure loss. If the airplane is above the suction feed 
altitude for the airplane/fuel type combination, an EICAS message on fuel 
system pressure loss will be displayed when cavitation occurs and the engine 
driven pump pressure drops below threshold. The difference between fuel 
boost pump failure indications and those for engine driven fuel pump failure 
would be that a sequence of indications would occur for the boost pump failure 
but only the fuel system pressure message would occur for engine driven 
pump failure. Action alternatives for the two failures would be quite different. 

Fuel flow does not change until flame out occurs. As the engine spools down 
following flame out, an EICAS message indicating the generator on the 
affected engine is off. For subtle faults producing a flame out, this message is 
often the first indication of an event. This may be the event to the crew; 
however, it is not the event of interest. 

The altimeter reading combined with fuel type information would provide 
information on whether the airplane was above suction feed altitude. 
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Quality of Data : 


Switch lights and EICAS messages are triggered by parameters breaking 
thresholds. No analog data on fuel pressure changes is available in the 
cockpit. Thus, there is no information indicating a flame out is imminent and 
no indication that it has occurred until the fuel system pressure and A/C 
power loss messages appear. 

Heuristics or Rules of Thumb Used : 

None identified. 

Time Constraints : 

At high altitude cruise without fuel boost pump pressure, pilots have 
approximately 15-20 seconds to detect the failure and take appropriate action 
before flame out occurs. 

Comments : 

At altitudes where suction feed is only partially effective and cavitation is 
beginning, the indications of fuel boost pump failure (or failure to turn on boost 
pumps during climbout) will include fluctuations in fuel flow, and eventually, 
fluctuating rotor speeds. Because fuel flow data is heavily massaged before 
being displayed on EICAS, this source of information will not be indicative of a 
problem until well after pump failure. 

If a single fuel boost pump fails, no change is required in configuring the fuel 
system because each tank has at least two boost pumps in it. Also, the 
airplane must be above the altitude at which fuel cavitation occurs for that 
particular plane/fuel combination. To have a flame out due to a fuel boost 
pump related problem, one must a) be above suction feed altitude, and b) have 
partial or total A/C power loss (depending on the airplane model), or c) have 
multiple pump failures in the same tank under special fuel system 
configuration conditions. EICAS messages will indicate low fuel pressure due 
to pump failures or A/C generator failures. However, generator failure 
messages will also appear when engines spool down below a certain RPM 
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following flame out even though there is no problem with the generator per se. 
The yaw produced by loss of an engine would probably not be felt in the cockpit 
if the autopilot were engaged. Loss of airspeed, throttle lever movement, 
attitude change, and possible initiation of drift down would be other indications 
the crew might have that an engine had been lost. 

Information Required to Make Diagnosis 

Kev Parameters : 

Fuel Boost Pump Output Pressure 

OR 

Engine Driven Fuel Pump Pressure 

AND 

Fuel System Configuration 
Altitude 

Symptoms : 

When at high altitude cruise: 

Fuel boost pump output pressure drops to zero. 

Fuel system pressure drops as a step function by approximately 25 lbs. and 
levels off for approximately 15-20 seconds then drops by another step function to 
about 25 lbs. 

Flame out occurs in less than 5 seconds after the precipitous drop in fuel 
system pressure. 

When at transitional altitude: 

Fuel boost pump pressure drops to zero. 

Suction feed is only partially effective in supplying fuel, to engine driven pump. 
Fuel system pressure fluctuates below what it would be with boost pumps on. 
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Fuel flow begins to fluctuate below cruise level. 

High rotor speed begins to fluctuate and gradually fall off. 

Interpretation : 

The 25 lb. step function drop in fuel system pressure is the event signalling 
fuel boost pump failure. If the airplane is above the suction feed altitude limit, 
pilots have 15-20 seconds to take action to prevent a flame out. If the airplane is 
in the transition zone, fuel system pressure, fuel flow, and high rotor speed 
will begin to fluctuate with ever increasing excursions and fuel flow and high 
rotor speed will begin to decrease. 

Information Required for Decision Aiding 

Nature of the Fault : 

Selection of or recommendation of the appropriate action alternative requires 
knowledge of the nature of the fault or fault/action class. The components of 
that knowledge are: 1) a flameout is imminent; 2) the engine is not receiving 
adequate fuel; and 3) whether the fault is electrical, mechanical, or procedural 
in nature. The actions required to deal with the fault are different for the three 
types of fault. Each require the reconfiguration of systems but the specific 
actions are quite different. 

Relevant Context Variable Set : 

See earlier listing of context variables where relevant variables have status 
values provided. 

Relationship Between Fault and Context Variables for : 

Diagnostic Application - Loss of fuel boost pressure below the suction feed 
altitude limit will not result in a flame out. Loss of fuel boost pressure with the 
crossfeed valve open will not result in a flame out. The airplane/fuel type 
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combination will determine the suction feed altitude limit. Knowledge of the 
altitude of the airplane is a factor in determining the cause of low fuel 
pressure. 


Action Recommendation Application - Action options can be exercised in turn 
until the problem is solved. 

.Congeque nc e s . Qf Inappropriate Alternative Actions : 

Failure to properly configure the fuel system could lead to loss of up to four 
engines. 



FLIGHT DECK ENGINE ADVISOR 
FAULT SCENARIO - F3 


Event : Thrust Shortfall at TOGA 
Fault : FOD - Ice Ingestion: light damage 
Potentia l Fault Alternatives : 

FOD - bird ingestion 
Relevant Context Variables - Status 
Phase of Flight - Climb out 
Weather - Icing conditions 
FARs - 

Engine Fault History - 
Airline Policy - 

Engine Commanded Status - Climb power 

Pilot Error - Engine anti-ice system not turned on before entering icing 
conditions 

Airplane System Status - Engine anti-ice system activated after moderate ice 
build up on engine cowl and/or spinner 

Workload - Moderate 
Action Alternatives 

Continue to operate damaged engine at current power set tin g 
Continue to operate damaged engine at reduced power setting 
Shut down and secure damaged engine with restart option later in flight 
Shut down and secure damaged engine for duration of the flight 
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Subsystems Affected 
Engine 

Thrust Management System (Autothrottle) 

Propagation Sequence with Ran k Order Time Base 

Time t - Ice strikes fan blades 

Time tl - Vibration in low speed rotor increases approx. .5 units as a step 
function. Vibration in high speed rotor increases as a step 
function by approximately the same magnitude. No change is 
discernible in any other parameters. 

Time tn - Ice-damaged engine does not produce commanded thrust level 

Data Available to Pilots 
Source of Data : 

Lower EICAS display of vibration 
Explanation of Relationships : 

Foreign object damage (FOD), in this case caused by ice ingestion, produces an 
abrupt change in the level of vibration in the engine while all other parameters 
remain normal. This indicates some level of fan or compressor blade damage. 
The damage in turn reduces by some amount, directly related to the extent of 
the damage, the amount of thrust shortfall experienced for a given throttle 
setting. At low to moderate levels of FOD, pilots may not notice the relatively 
small step increase in vibration level. Therefore, they would have no reason to 
test thrust indication for shortfall. If the step increase were noticed, an 
indication of shortfall to be expected under TOGA conditions could be 
ascertained by advancing the throttles to maximum power and comparing 
expected with achieved thrust indications. It is possible at altitudes above 
FL170 for the engine controller to derate thrust and thus preclude detection of 
thrust shortfall. 
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Quality of Data : 


The vibration display on EICAS is graduated in arbitrary units. The source of 
vibration may be the frequency band monitored for the high speed rotor, the 
band monitored for the low speed rotor, or what is referred to as broad band 
vibration which is vibration measured over a wider band of frequencies which 
includes the bands measured for the low and high speed rotors. Engines vary 
considerably in their inherent vibration characteristics. Therefore, a specific 
vibration reading has little generalizable meaning unless it is in the caution 
range. Most engines do not even have caution range designations. Thus, the 
pilots are left to judge the criticality of vibration level without guidance. 

Vibration may appear to be an obvious cue, but cross-engine comparisons of 
readings on the vibration instrument may not be helpful. These instruments 
report the highest level of vibration present in one of three frequency bands 
being monitored. A scan of the vibration gauges will not necessarily allow the 
pilots to compare broad band vibration levels across engines. Each of the two 
or four engines could be displaying vibration level from a different source. 

The effects of light ice damage on thrust shortfall may be so subtle that they 
would not be detected by the crew - until they needed TOGA power. As with 
any FOD fault, the projection of engine performance and integrity over time is 
a very important piece of information pilots need in their decision makin g but 
one that is very difficult to predict unless the exact nature and extent of 
damage is known. 

Heuristics or Rules of Thumb Used : 

None identified. 

Time Constraints : 

(See comments under this heading in the moderate and heavy ice damage 
fault scenarios.) 
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Information Required to Make Diagnosis : 

Kev Parameters : 

Vibration 

Primary Thrust Indicator 
Symptoms : 

The relatively small (.5 unit) step function change in vibration level is the only 
symptom across all engine parameters indicating the presence of ice damage 
until max power is applied. The relevance of going to max power to produce 
the thrust shortfall indication is tempered by comments made earlier that, 
depending on the altitude, the engine controller may thwart attempts to check 
for thrust shortfall in the damaged engine. 

Interpretation : 

As can be seen, the symptoms for diagnosing light ice damage are extremely 
subtle. Detection of the damage requires; a) that the step function increase in 
vibration be detected, and b) that the difference in vibration level before and 
after damage has occurred can be recognized as a reliable symptom. The 
confirming factor is the recognition of thrust shortfall. With light damage, the 
task may not be easy or even possible. What makes detection important is the 
potential for engine performance degradation to levels critical to flight safety 
either within the time frame of the current flight or on subsequent flights, if 
undetected. A worst case scenario would be loss of the engine near VI on take 
off on a subsequent flight. 

Information Required for Decision Aiding 
Nature of the Fault : 

Ice ingestion has caused light damage to fan blades. 

Further deterioration, if any, which might occur in available thrust within the 
duration of the current flight. 
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Relevant Context Variable Set : 

The relevant context variable set is composed of those variables listed earlier 
which have status information included. 

Relationship Betwee n Fault and Context Variables for ; 

Diagnostic Application - If different types of FOD result in different projections 
of engine performance and or integrity, then context variables may be useful in 
relevant differentiation among FOD faults. Phase of flight, weather, and 
airplane system status will aid in differentiating ice damage from other FOD 
faults if appropriate. 

Action Recommendation Application - Pilots may have the widest range of 
action alternatives in this situation depending on the need for TOGA power 
from the affected engine and the projected effect of maintaining thrust 
setting(s) at the desired or required levels. 

Consequences of Inappropriate Alternative Actions: 

Acceleration and deceleration of the affected engine could lead to additional 
damage if ice is dislodged from the spinner. 
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FLIGHT DECK ENGINE ADVISOR 
FAULT SCENARIO ■ F4 

Event : Thrust Shortfall at cruise power and above 
Fault : FOD - Ice Ingestion: moderate damage 
Potential Fault Alternatives: 

FOD - Large bird ingestion 
FOD - Multiple bird ingestion 
Fan blade tip loss 

Relevant Context Variables - Status : 

Phase of Flight - Climb 
Weather - Icing conditions 
FOD Potential - Moderate 
FARs - 

Engine Fault History - 
Airline Policy - 

Engine Commanded Status - Climb power 

Pilot Error - Engine anti-ice system not turned on before entering icing 
conditions 

Airplane System Status - Engine anti-ice activated after moderate ice build up 
on engine cowl 

Workload - light to moderate 
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Action Alternatives 

Continue to operate damaged engine at current power setting 
Continue to operate damaged engine at reduced power setting 
Shut down and secure damaged engine with restart option later in flight 
Shut down and secure engine for duration of the flight 

Accelerate and decelerate engines. Check instruments for vibration levels, 
sluggish acceleration, thrust shortfall. 

Subsystems Affected 
Engine 

Thrust Management System 
Propagation Sequence with Time Bast* 

Time t - Precise timing on occurrence of moderate ice damage unknown 

Time tl - Climb power commanded. Small thrust shortfall occurs at climb 
power. Low rotor speed on target. High rotor speed shows 5% 
shortfall. EGT and fuel flow slightly below expected values for 
thrust setting. Increase in vibration on low speed rotor precedes 
normal onset and exceeds expected value by 25%. Spike in high 
speed rotor vibration as climb power is commanded then drop to 
expected level. 

Time t2 - Cruise power commanded. Thrust shortfall increased slightly 
from climb power shortfall. High rotor speed at expected level. 
EGT and fuel flow remain slightly lower than expected. Vibration 
in low speed rotor remains 25% above expected. Vibration in high 
speed rotor averaging 200% higher than expected level. 
Acceleration to commanded thrust level is slightly slower than 
expected. 
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Data Available to Pilots 
Source of Data : 

EICAS display: vibration and related thrust parameters 
Explanation of Relationships : 

No time marker is available to indicate the onset of ice ingestion which causes 
moderate damage. Therefore, differences in vibration level must be evaluated 
when power levels are changed rather than detecting a step function in 
vibration level as an indicator of damage having occurred as was the case with 
light ice damage. Interestingly enough, vibration levels and thrust shortfall 
appear greater when cruise power is commanded than when climb power is 
set and thrust shortfall, as indicated by the primary thrust parameter, is also 
greater at the cruise setting (albeit by a small amount). The differences 
between high rotor speeds and high speed rotor vibration at the two power 
settings will make it difficult to use these information sources in generating 
rules for diagnosing deviation patterns. Vibration, and particularly high 
speed rotor vibration again seems to be the only clear indication of damage. 

The problems pilots have in trying to interpret the vibration parameter have 
already been discussed in the scenarios on light and heavy ice damage. The 
other indications such as EGT and fuel flow shortfall as well as the high rotor 
speed shortfall at climb power are subtle and would not likely be noticed in the 
cockpit. These differences will likely fall within the noise band of MONITAUR 
deviation detection and will not provide symptoms for diagnosis. 

.Qu ality of Data : 

Factors which relate to the quality of the data as presented to pilots have been 
discussed above. These are: small differences in parameter levels across 
engines; inconsistent differences in parameter levels at different power 
settings; and the problem of interpreting changes in vibration level without 
clear guidelines. 
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Heuristics or Rules of Thumb Used : 
Time Constraints : 


This issue of time constraints is the same as with light and heavy damage 
conditions. A great deal depends on phase of flight. The current data set was 
obtained in climb and cruise. Thus, time constraints in dealing with the 
problem are not serious. 

Information Required to Make Diagnosis 
Kev Parameters : 

Thrust parameter 
High rotor speed 

Vibration : High and Low speed rotors 
Fuel Flow and EGT may be secondary 
Symptoms : 

Slight shortfall in thrust parameter at climb power 
Slight shortfall in high rotor speed at climb power 

Moderate elevation of expected level of vibration in low speed rotor at climb 
power 

Marked increase in vibration level on high speed rotor at climb power 
Interpretation : 

In the final analysis, the only reliable symptoms indicating f an and/or 
compressor damage are the step function increases in vibration level 
regardless of the source of the vibration reading. Vibration measurement for 
low and high speed rotors and the broad band measure are described in the 
fault scenario on light ice damage. 
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Information Required for Decision Aiding 
Nature of the Fault : 

The pattern of symptoms found 'with moderate ice damage differs from those 
found with light and heavy damage. The consistent theme across all levels of 
damage is the increase in vibration level. In the long run, when vibration 
levels and patterns in modern jet engines are adequately understood, this 
parameter should be very useful in diagnosing the existence of FOD and 
predicting the time course and levels of deterioration in engine performance 
and integrity which results. In the meantime, step function increases in 
vibration levels remain the only reliable indication of compressor damage. If 
the damage is severe, other engine parameters will begin to deteriorate. 

Relevant Context Variable Set : 

The relevant context variable set is comprised of those variables listed earlier 
which have a status indicated. 

Relationship Between Fault and Context Variables for : 

Diagnostic Application - It is not clear at this point whether distinguishing 
between objects ingested is useful in terms of implications for crew actions. 
The utility of such a distinction probably lies in determining whether the time 
course of deterioration in engine performance and/or integrity is changed as a 
function of the object ingested. To the extent that it is, then it becomes 
important to make the diagnostic distinction in order to provide the crew with 
the information they need to properly determine their course of action. 

Action Recommendation Application - Action alternatives very greatly in this 
situation depending on the need for power from the affected engine and the 
projected effect of maintaining throttle setting(s) at desired or required levels. 
If projected effects could be determined with enough accuracy and reliability, 
this information would be very valuable to the pilots in deciding among 
possible courses of action. 
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Consequences of Inappropriate Alternative Actions : 

Acceleration and deceleration of engine could lead to additional damage if ice 
is dislodged from spinner. 
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FLIGHT DECK ENGINE ADVISOR 
FAULT SCENARIO - F5 


Event : Thrust Shortfall at cruise power and above 
Fault : FOD - Ice Ingestion: heavy damage 

Potential Fault Alternatives : 

FOD - Large bird(s) ingestion 

Fan blade tip(s) loss 

Relevant Context Variables - Status : 

Phase of Flight - Cruise 
Weather - Icing conditions 
FOD Potential - high 
FARs - 

Engine Fault History - 
Airline Policy - 

Engine Commanded Status - Climb power 

Pilot Error - Engine anti-ice system not turned on until major build up of ice 
occurs on cowling and/or spinner 

Airplane System Status - Engine anti-ice OFF 

Workload - light to moderate 

Action Alternatives 

Continue to operate damaged engine at current power setting 
Continue to operate damaged engine at reduced power setting 
Shut down and secure damaged engine with restart option later in flight 
Shut down and secure engine for duration of the flight ' 
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Accelerate and decelerate engines. Check instruments for vibration levels, 
sluggish acceleration, thrust shortfall 

Subsystems Affected 
Engine 

Propagation Sequence with Time Base 

Time t - Timing on occurrence of heavy ice damage unknown 

Time tl - Cruise thrust commanded. Acceleration to commanded thrust 
level is slower than expected. Thrust shortfall occurs at climb 
power. Achieved thrust is approximately 80% of commanded. 
Low rotor speed acceleration normal; high rotor speed slower 
than expected. Fuel flow and EGT lower than expected. 
Broadband vibration level increases 3 units above expected level. 

Time t2 - At commanded thrust level, low and high speed rotor vibration at 
expected levels. Broadband vibration remains 3 units higher than 
expected on ice damaged engine. 

Data Available to Pilots 
Source of Data: 

EICAS display: vibration, thrust parameters, cross engine comparisons 
Explanation of Relationships : 

No time marker on the occurrence of heavy ice ingestion was available in the 
data base. Therefore, the step increase in vibration apparent with initial light 
ice damage was not available. It is not known if such a step increase would 
have occurred. The vibration symptom only becomes apparent when the 
throttle on the ice damaged engine is advanced in concert with throttle 
advance on the normal engine. Changes in vibration levels in the ice damaged 
engine on low and high speed rotors are evident with light and moderate ice 
damage but do not show up with heavy damage.- Instead, the vibration 
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symptom evident for heavy damage is a marked increase in broad band 
vibration. The reliability of this difference in symptoms cannot be ascertained 
without comparable duplication of the incident and/or verification by expert 
opinion. The extent of damage is clearly evident in the amount of thrust 
shortfall which occurs at higher power settings. The shortfall with light ice 
damage is only evident under TOGA power settings. Moderate ice damage 
results in a slight shortfall at climb power. Whereas with heavy ice damage, 
the shortfall is very evident even at cruise power (i.e., approximately 80% of 
normal). Thus, heavy damage may be more easily detected than light or 
moderate damage. Although, the problem noted in regard to light damage 
(i.e., where in some cases above FL170 the engine controller may derate thrust) 
could mitigate the value of throttle movement as a source of information about 
the extent or possibly even the presence of thrust shortfall. 

Changes in vibration level, while obvious when viewing the data printouts, 
may not be obvious or even detectable on vibration indicators in the cockpit. 

Quality of Data : 

Pilots must rely oh memory and cross engine comparisons to detect the 
problem and assess severity. Neither source provides high quality 
comparative data. Pilots must detect the step increase in vibration as such as 
a major initial symptom of FOD. If the damage is light, this is a very difficult 
task. With heavy damage, the problem is more obvious and the action 
alternatives more limited. Thrust shortfall with light to moderate damage will 
only be detected at relatively high power settings (the lighter the damage, the 
higher the power setting must be to detect the shortfall). Cross engine 
comparisons mav provide evidence of damage but normal engine differences 
in vibration and thrust can mask the effects of light to moderate damage. The 
same can be said of differences across engines in thrust and rotor speed 
acceleration. 

Heuristics or Rules of Thumb Used : 

None identified. 
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Time Constraints : 

Whether time constraints exist will depend on phase of flight. The data which 
support this scenario were gathered during climb out and cruise. Thus time 
would be available to assess the problem and determine action options without 
serious constraint. If the icing and damage had occurred during descent, the 
time available for diagnosis and planning could be constrained. However, the 
need for maximum power under these conditions would only occur if a go 
around were required. 

Information Required to Make Diagnosis 

Kev Parameters : 

Vibration 

Thrust 

Low and high rotor speed 
Symptoms : 

Noticeable (e.g., 20%) thrust shortfall at cruise power settings; i.e., engine is 
producing only 80% of the thrust normally expected at the throttle setting used. 

Thrust acceleration below expected when throttle advanced. 

Both low and high speed rotor vibration normal 

Broad band vibration 3 units higher than expected on ice damaged engine 
Interpretation : 

As can be seen, the symptoms for diagnosing even heavy ice-induced damage 
are quite subtle. Vibration may be an obvious cue, but cross-engine 
comparisons of readings on the vibration instrument may not be helpful. 

These instruments report the highest level of vibration present in one of three 
locations on the total bandwidth of frequencies monitored; i.e., frequency 
windows for low or high speed rotor and broad band. A scan of the vibration 
gauges will not necessarily allow the pilots to compare broad band vibration 
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levels across engines. Each of the two or four engines could be displaying 
vibration level from a different source. 

The ice damage fault is an example of the type of fault which may require pilot 
action to provide the type of information really needed to complete the diagnosis 
of a fault or even to make the crew aware of the presence of an event; i.e., that 
there is a definite thrust shortfall in the affected engine. This presents some 
interesting issues. Is it possible that a different fault may lead to the same 
event, but the pilot action required to fully diagnose the ice damage fault would 
have serious negative consequences such as loss of the engine for the duration 
of the flight? Addressing these issues fully is beyond the scope of the present 
analysis. 

The three fault scenarios on ice damage are the closest thing we have to trend 
data. The change in symptoms which represent damage at different levels is 
interesting to note. We do not know at this point whether the pattern of 
changes in relevant symptoms will generalize across FOD faults. Nor do we 
know what further deterioration in engine performance and integrity will 
occur as a function of continuing to operate the engine at a particular power 
setting 2 . Although propulsion engineers may be able to provide general, 
qualitative projections, they are not willing to do so formally. In the real 
world, predictions on performance trends and integrity may range in 
importance from useful to critical depending on phase of flight. 

Information Required for Decision Aiding 

N ature . Qf the , Fault : 

Clearly, the extent of the ice damage is an important factor in decisions which 
involve the availability of thrust. The detection of thrust shortfall and the 
prediction of additional deterioration in engine performance and integrity is 
important regardless of the specific nature of the FOD fault. Because of the 


2 The engine on which data were gathered was operated for several hours after the damage 
occurred. However, it would not have been had the pilot realized the extent of the damage 
incurred. 
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procedure used in inducing ipe damage, we can not be sure that the symptom 

pattern would be the same with say the ingestion of small, medium, and large 

birds. That is, the sudden onset of FOD at different levels of damage may 

produce a different pattern of symptoms. 

% 

There should be additional contextual information available which would 
allow the diagnostic system to differentiate among at least some of the fault 
alternatives which could lead to the event in question - thrust shortfall. 

Relevant Context Variable Set : 

The relevant context variable set is comprised of those variables listed earlier 
which have a status indicated. 

Relationship Between Fault and Context Variables for : 

Diagnostic Application - If different types of FOD result in different projections 
of engine performance and or integrity, then context variables may useful in 
relevant differentiation among FOD faults. Several factors will aid in 
differentiating between ice damage and at least one other fault alternative, 
namely large bird ingestion. Phase of flight is cruise (although not high 
cruise) thus greatly reducing the odds of bird ingestion 3 . Icing conditions are 
present and the anti-ice system(s) are not on. Workload is such that requiring 
pilot action to generate additional symptoms is not out of the question. 

Action Recommendation Application - Action alternatives very greatly in this 
situation depending on the need for power from the affected engine and the 
projected effect of maintaining throttle setting(s) at desired or required levels. 
If projected effects could be determined with enough accuracy and reliability, 
this information would be very valuable to the pilots in deciding among 
possible courses of action. The British Midlands crash is an example of 
depending on an engine with FOD (fan blade tip loss and ingestion) as, in that 


3 Although there has been at least one report of an eagle striking the windscreen on a 
commercial transport jet at cruise altitude. 
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case, the only source of power. The pilots need information as to what they can 
count on in the way of thrust tender all relevant circumstances. 

Consequences of Inappropriate Alternative Actions : 

Acceleration and deceleration of engine could lead to additional damage if ice 
is dislodged from spinner. Depending on the engine and the nature of the 
FOD, throttle movement of any kind may be very inappropriate. 
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FLIGHT DECK ENGINE ADVISOR 
FAULT SCENARIO - F6 


Event : All Engine Flameout 

Fault : FOD - Volcanic ash ingestion producing fuel nozzle clogging 

Potential Fault Alternatives : 

Mismanaged fuel system configuration 


Relevant Context Var iables - Status; 

Phase of Flight - Descent 

Weather - Broken clouds below. Thin layer of "white clouds" at FL260 
FOD Potential - High, volcanic eruption in area 
FARs - 

Engine Fault History - 

Airline Policy - with regard to use of Autostart 

Engine Commanded Status - Before encountering ash, Low rotor speed at idle. 

Subsequent commands were 60%, 80%, Max Power, 80%, Max 
Power. Engines were at commanded Max Power when power loss 
began. 

Pilot Error - Throttle advances not advised under circumstances 4 . 

Airplane Systems Status - All operating normally 
Workload - Moderate, before flameout 

Training/Procedures - Event/fault combination not anticipated 
Action Alternatives : 

Airspeed to middle of start envelope 


4 It is unfair to label the crew action as pilot error for the particular incident on which data were 
available because the crew performed as trained and on the basis of information available in 
Ops Manuals at the time. Adjustments to training and Ops Manuals have since been changed 
to reflect appropriate action alternatives. 
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Attempt immediate restart (manual or auto) 

Execute shutdown/restart procedures 

Reduce throttles to idle while in vicinity of ash cloud(preventative measure) 
Engines 1 & 4 (or left) to idle, use 2 & 3 (or right) as needed 



Engines 


Engine driven electrical and hydraulic subsystems drop off line as engine 
spool down below idle, but this information plays no role in fault identification. 


Time t 


Proximity to volcanic ash cloud realized 


Time tl - Low rotor speed increases on all engines - commanded 


Time t2 - Descent halted 


Time t3 - Max power applied and airplane begins to climb 
Time t4 - Climb stops at 28000 feet 

Time t5 - High and low rotor speed on all engines drops sharply 


Time t6 - Sharp rise in all EGT’s accompanied by decreasing high rotor 
speed 

Time t7 - All engines go sub-idle 

Time t8 - All engine flameout has occurred, all generators drop off line 



Visual sighting of ash cloud 

EICAS display of engine parameters 

ATC relayed reports of location of ash cloud 
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Explanation of Relationship^ : 

In this case, the information needed to select the appropriate action alternative 
is available only through hindsight and much testing. The actions taken in 
this case were exactly the opposite of those which should have been taken. 
Increasing power while ingesting volcanic ash accelerates the sooting or 
coking action on the turbine fuel nozzles which in turn starves the engine of 
fuel. Diagnosis of the fault requires information beyond the airplane; i.e., 
visual sighting of the ash cloud and/or communications from ATC or other 
aircraft. There is no pattern of engine parameter behavior which would alert 
the crew to impending FOD from volcanic ash. Neither is there a pattern in 
engine parameter behavior on which the monitoring and diagnostic modules 
could reason. Selecting the correct action alternative depends on recognition of 
external conditions and training as to the appropriate action(s) in the presence 
of these conditions. 

Quality of Data : 

No information is available to the pilots from flight deck instrumentation 
which would allow them to predict the potential for an all engine flameout. 

The "data" available for dealing with this situation would be training and 
experience. 

Heuristics or Rules of Thumb Used : 

To avoid trouble - climb 
Time Constraints : 

Time constraints for an all engine flameout are a function of altitude. 

However, any time all power is lost on all engines, time will be perceived as 
being very short indeed. 

Information Required to Make Diagnosis 
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Kev Parameters: 


Fuel Flow 

Low and High Rotor Speeds 
EGT 

Symptoms : 

The initial symptom would be the deviation of actual fuel flow from fuel flow 
needed to achieve commanded thrust level. Propagation symptoms include a 
rapid loss of high and low rotor speed accompanied by rapidly increasing EGT. 
These latter symptoms are evident in the cockpit, but by the time they appear 
the flameout cannot be avoided. 

Interpretation : 

The time frame from onset of the coking action to flameout is not known but is 
dependent upon power settings. The DFDR data would indicate that the time 
frame may be very short indeed if inappropriate thrust commands are 
implemented. 

An accurate measure of actual fuel flow compared to the engine controller 
"model" of fuel flow for commanded thrust level would show the inconsistency 
in fuel flow needed for commanded thrust vs. that being achieved. This a case 
where all the information MONITAUR would require to identify the deviation 
is available in the engine controller but is not available to the crew. 

Information Required for Decision Aiding 
Nature of the Fault : 

This fault represents and interesting challenge because it involves the need for 
information external to the airplane for accurate diagnosis. It also represents 
an example of where context variable status is critical to accurate diagnosis. 
The requirement for accurate diagnosis to the specific fault level is still under 
study. The question is How does appropriate crew action differ for flameout 
from fuel nozzle clogging due to volcanic ash ingestion ys. say flameout due to 
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water ingestion? In this particular comparison, the answer is interesting. 
When in the presence of or about to encounter volcanic ash, retard the 
throttles. When ingesting large amounts of water, advance throttles to full 
power. If use of the autostart system is the answer for all faults in this and 
related categories, then the mapping of Event/Fault combinations via context 
variables to appropriate action alternative will be a simple, straightforward 
relationship. If not, the Flight Deck Engine Advisor system may require pilot 
input to complete the diagnostic process. The example given just above 
suggests the relationship will not be simple or straightforward. 

Relevant Context Variable Set : 

Phase of Flight - Descent 

Weather - Broken clouds below. Thin layer of "white clouds" at FL260 

FOD Potential - High, volcanic eruption in area 

Airline Policy - especially with regard to use of Autostart 

Pilot Error - Throttle advances not advised under circumstances. 

Airplane Systems Status - All operating normally 
Workload - Moderate, before flameout 
Relationship Between Fault and Context Variables for : 

Diagnostic Application - Accurate diagnosis requires timely information on 
deviations in fuel flow from normal for commanded thrust level and external 
information about the potential for FOD from volcanic ash in the vicinity. 

Action Recommendation Application - The relationship of this particular 
Event/Fault combination to action alternatives has not been determined as yet. 
The determination will hinge on the effectiveness of potential crew actions on 
correcting or mitigating the effects of volcanic ash ingestion. 

Consequences of Inappropriate Alternative Actions : Advancing the throttles 
to max power when ingesting volcanic ash produces the conditions within the 
engine which result in a flameout; i.e., temperatures are increased and the 
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coking or clogging of fuel nozzles results in reduced thrust and eventually 
flameout - the higher the power setting called for, the greater the coking 
action. Thus, advancing throttles in the presence of volcanic ash is an action 
alternative to be avoided. Without appropriate instructions on the appropriate 
action coupled with pilots' conditioned response to climb out of trouble, the 
stage is set in these circumstances for an all engine flameout. 
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FLIGHT DECK ENGINE ADVISOR 
FAULT SCENARIO - F7 

Event : Hung Start - Air 

Fault : Fuel nozzle coking (due to ingestion of volcanic ash) 
Potential Fault Alternatives : 

Pneumatic System Faults 

- Pneumatic pressure too low 

- Airplane pneumatic duct failure 

- Starter air valve failure 

- " " duct failure 

- Starter failure (partial failure results in too little torque 
Fuel System Faults 

- Fuel metering unit 

- Fuel shutoff valve 

- Engine fuel pump 

- fuel boost pump (high altitude air starts) 

- Engine fuel line 

- Mismanaged fuel system configuration 

- Crossfeed valve failure 
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Start Procedure Faults 

- Airplane pnetimatic system improperly configured 

- Too cold: failure to use RICH; improper selection of 
fuel; too cold even for RICH 

- Outside of start envelopes 

- Fuel pressurization when high rotor speed too low 

Gas Generator Faults (Compressor/Turbine) 

- Bleed valve failure 

- Stator vanes off schedule (mechanical failure) 

- Compressor damage 

- Turbine damage 

- Low speed rotor locked (stuck) 

Engine Control Faults 

- Sensor fault 

- Software error 

- Hardware failure 

- Actuator failure 

- Engine wiring (e.g., intermittent broken connection between engine 
controller and fuel metering unit) 

Relevant Context Variables - Status : 

Phase of Flight - Descent 

Weather - High thin clouds 

FOD Potential - High, volcanic eruption in area 

FARs - 

Engine Fault History - 
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Airline Policy - Autostart system use not mandatory 
Engine Commanded Status - Start 

Pilot Error - Autostart system OFF; Failure to distinguish between air and 
ground start characteristics 

Airplane Systems Status - All engines flamed out; battery standby power only 
available. Windmilling start required. 

Workload - High; Stress level extremely high 


Action Alternatives : 

Activate Autostart system (if available) 

Execute shutdown and manual restart procedures - single engine 
Execute shutdown and manual restart procedures - multi-engine 

Subsystems Affected : 

Engine(s) 

All airplane systems are affected. Normally however, the PFD, ND, and upper 
EICAS will remain on being powered as they are by the standby bus. 

Propagation Sequence With Time Base : 

Start sequence data plots are truncated due to generators dropping offline and 
resulting loss of power in flight deck recorders. Several hung starts occurred 
in start attempts on three of four engines during the course of the event. The 
sequence reported below will be an amalgamation of data across engines and 
start attempts. 
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t(unknown) - Engine start initiated 

Time tl - Low rotor speed at approximately 24%; high rotor speed nearly 
level at 45%; EGT at 510 deg. C.; fuel flow nearly flat at 800# 

Time t2 - low rotor speed flat at 24%; high rotor speed nearly flat at 46%; 
EGT rising rapidly at 540; fuel flow nearly flat at 850# 

Time t3 - low rotor speed flat; high rotor speed nearly flat at 48%; EGT 
rising rapidly to 610; fuel flow nearly flat at 900# 

Time t4 - Start attempt aborted 


Pilots use high rotor speed to indicate appropriate time to turn fuel ON then go 
by the "clock" (real time monitored or estimated) to determine if "light off has 
occurred normally. Light off can take 2 to 3 minutes in an air start. Once light 
off has occurred, they monitor high rotor speed and EGT to determine if a start 
is progressing normally. Fuel Flow (FF), EGT, and low rotor speed also have 
appropriate rates of increase during a normal air start. However, this rate of 
change for each parameter can differ somewhat from that achieved during a 
ground start. On the ground, if a normal start is not achieved, high rotor 
speed will begin to decline when a speed of 50% has been achieved and the 
starter disengages. In an air start with all engines flamed out, no bleed air is 
available to power the starter so a windmilling start must be accomplished. 
Rate of increase in engine parameters during such a start may be significantly 
slower than for a normal ground start. 



Upper EICAS is the only source of data on engine parameter behavior. The 
primary thrust parameter would be shown in full scale. All other engine 
parameters are shown in digital form only. 
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Explanation of Relationships : 


Quality of Data : 

The quality of the data available to the pilots on key parameters with only the 
upper EICAS available would not be degraded from normal. However, the 
"grain" of the data available normally is not fine enough to pick up trends in 
parameters until major departures from normal have occurred. 

Heuristics or Rules of Thumb Used : 

The typical high rotor speed/EGT relationship looked for is high rotor speed X 
10 = EGT during the initial stages of spool-up following light off. On the 
ground, a normal start should be accomplished in 45 to 60 seconds. In an air 
start however, the time frame for a normal start may be doubled, tripled, or 
more. 

The appropriateness of this rule of thumb varies across engines and is not 
applicable to an air start. 

Time Constraints : 

Light off normally occurs within 10 seconds after fuel ON for a ground start 
but may take 2-3 minutes in an air start. Stable parameter readings at idle 
should be achieved within one to two minutes for a ground start but can take 
much longer in an air start. Changes in the rates of change for high rotor 
speed and EGT are slower for an air start. Thus, hung and hot start 
indications will not be as obvious as they typically are in a ground start. 
Likewise, a normal start may be in progress, but if ground start criteria are 
used, a hung start may be assumed. 
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Information Required to Make Diagnosis 
Kev Parameters : 

High rotor speed 
EGT 

Fuel Flow 
Symptoms : 

High rotor speed remains relatively flat for up to 60 seconds or more after light 
off. EGT rises relatively quickly and fails to stabilize with evidence of normal 
spool up. Under the event/fault condition defined for this scenario (i.e., all- 
engine flameout) EGT exceedences would probably be ignored in the interest of 
getting an engine started. 

Interpretation : 

In this incident, the engine parameters during start exhibited typical 
hung/hot start characteristics. With fuel input low and relatively constant, 
combustion processes were not sufficient to drive the turbines, and 
consequently the high speed rotor, to normal idle speed. With high rotor speed 
low relative to normal, insufficient air was flowing through the engine relative 
to the amount of fuel available resulting in rapidly rising EGT. 

As many as twelve restart attempts were performed on some of the engines. 
For those restart attempts where data are available, the parameter values for 
high rotor speed and fuel flow improve slightly with each restart attempt until 
a normal start is achieved. 

Information Required for Decision Aiding 

Nature of the Fault : 

The fault is in the fuel system; specifically clogged fuel nozzles. Typically, 
with faults other than procedural faults there is little pilots can do to correct 
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the fault. However, speculation is that the numerous attempts to restart the 
engines may have aided in dislodging the coking on the fuel nozzles. 

Relevant Context Variable Set : 

Phase of Flight - Descent 

Weather - High thin clouds in area make it difficult to identify volcanic ash 
clouds 

FOD Potential - High, volcanic eruption in area 
Airline Policy - Autostart system use not mandatory 
Engine Commanded Status - Start 

Pilot Error - Autostart system OFF; possible failure to distinguish between air 
and ground start characteristics; advancing throttle to climb 
power accelerated coking process 

Airplane Systems Status - All engines flamed out; only systems powered by 
standby bus available 

Workload - High; Stress level extremely high 
Relationship Between Fault and Context Variables for : 

Diagnostic Application - Phase of flight is a major factor in diagnosing the 
fault. The rates at which parameters change during an air start are diff erent 
than the rates during a ground start. Rates which would indicate a hung start 
on the ground may be normal for an air start. All starter related items among 
the fault alternatives are eliminated if the starter is not available or not used. 

Action Recommendation Application - When in the vicinity of volcanic ash, the 
recommended action is to reduce power setting; e.g., pilots could reduce power 
on half their engines and use the other half for maintaining altitude or 
climbing. In the event of an all engine flameout, engine start attempts should 
be monitored closely to avoid shutting down engines which have a normal start 
in progress vs. those that have hung or hot starts in progress. 
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Consequences of Inappropriate Altern ative Actions; 

Advancing throttles to climb power in the presence of volcanic ash accelerates 
the coking or clogging process on the fuel nozzles. Appropriate action is to 
retard the throttles. This is coritrary to the natural tendency of pilots to climb 
out of trouble. 
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FLIGHT DECK ENGINE ADVISOR 
FAULT SCENARIO - F8 


Event : Stall/Surge 

Fault: Stability margin problem 

Potential Faul t Alternatives: 

FOD 

Procedural error 
Stator vane failure 
Bleed valve control failure 
Relev ant Context Variables : 

Phase of Flight - Take Off 
Weather - Clear and 15 
FOD Potential - 
FARs - 

Engine Fault History - prototype engine 
Airline Policy - 

Pilot Error - Throttle on affected engine should be retarded 

Airplane System Status - 

Workload - High 

Action Alternatives - 

Retard throttle on affected engine 

Retard throttle on affected engine, command full power on other engine(s) 
Subsyste ms Affected : 

Engine 
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Propagation Sequence with R ank Order Time 

Time tl - Beta stator vane angle showing high frequency, low amplitude 
fluctuations 

Time t2 - Fluctuations in Beta SVA increase in amplitude and become quite 
regular in pattern 

Time t3 - High response low pressure compressor (LPC) static pressure 
sensor 5 shows definite high frequency, moderate amplitude 
fluctuation 

Time t4 - High response LPC static pressure shows very definite high 
frequency, high amplitude fluctuations 

Time t5 - High response total LPC pressure beginning to show definite 
fluctuating pattern 

Time t6 - Standard LPC static pressure sensor 6 showing definite low 
frequency fluctuating pattern 

Time t7 - Fuel flow shows uncommanded 7 drop 


Time t8 - Low and high rotor speeds decelerate sharply 

Time t9 - EGT goes off scale several times at less than 1 sec intervals 


5 Sensor unique to flight test. 

6 Sensor is on some operational engines. Getting information on some of these parameters 
would be possible if the engine controller uses the information in it control laws. 

7 Throttle not retarded but engine controller cut fuel flow. ' 
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Data Pilots Have Available 


Source of Data : 

EICAS display of engine parameters 

The auditory indicators (pops and/or loud bangs) of surging 
Explanation of Relationships : 

The indications in the cockpit are after the fact. Engine controller commanded 
reduction in fuel flow occurs about 1.5 sec before the throttle is chopped. Low 
and high rotor speeds drop sharply when fuel flow is cut back. The EGT 
excursions may be displayed on the EICAS if the EICAS system does not damp 
high frequency oscillations. However, the excursions may not be seen by the 
pilots. 

Quality of Data : 

No information on the flight deck of im pending stall and surging. This type of 
information (were it available) should be processed through an engine advisor 
system and presented to the crew as an alert. 

Heuristics or Rules of Thumb Used : 

None identified 

Time Constraints : 


The data from special flight test instrumentation provides a clear indication 
that stalls and surges are developing up to 15 seconds or more before the surge 
occurs. With operational sensors a 5 second warning may be possible. This is 
still adequate for crew action. However, the appropriate action depends on 
where the airplane is in terms of phase of flight. With the case in point, the 
actual stall occurred very early in initial climb. Here the appropriate action 
would be to retard the throttle on the affected engine and command full throttle 
on the remaining engine(s). With 15 seconds warning and assuming at that 
point the airplane was below VI, the appropriate 'action would be to abort the 
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takeoff; if above VI and at a safe altitude, retard throttle as required and 
command full throttle on other engine(s). During climb, TOC, TOD, or 
descent, time constraints are less critical and appropriate action is to retard 
the throttle. 

Information Required to Make Diagnosis 
Kev Parameters : 

Beta Stator Vane Angle - an operational sensor but data not available to the 
flight deck 

High Response Discharge Static Pressure at Low Pressure Compressor - 
special flight test instrumentation 

High Response LPC Discharge Total Pressure - special flight test 
instrumentation 

Standard LPC Discharge Static Pressure - operational instrumentation but 
data not available to the flight deck 

All engine parameter data available on EICAS display the results of the stall 
and surging; i.e., fuel flow, high and low rotor speeds, EGT. 

Neither the stator vane angle sensor nor the discharge pressure sensors are 
represented in the engine model or MONITAUR. 

Symptoms : 

At time tl - The earliest indication of a problem developing appears to be the 
high frequency oscillation of Beta stator vane angle. However, 
stator vane angle is on steady state schedule; i.e., the level of the 
parameter is alright. Since it is' on schedule, stator vane failure 
can be eliminated as a potential fault alternative. The very high 
frequency oscillation does not appear in the stator vane angle data 
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after recovery although oscillation is still present and amplitude 
is reduced. 

At time t2 - Beta SVA oscillations increase in frequency and amplitude. 

At time t3 - High response LPC static pressure has definite high frequency, 
moderate amplitude oscillations. 

At time t4 - High response LPC static pressure has very definite high 
frequency, high amplitude oscillations. 

At time t5 - High response total LPC pressure beginning to show definite 
oscillations 

At time t6 - Standard LPC pressure showing definite oscillating pattern 
Interpretation : 

The problem here from the standpoint of Engine Advisor development is that 
we have sensor data that clearly indicates the onset of stalls and surges; BUT, 
the best indications come from delicate flight test sensors, AND we have no 
engine model parameter data for these sensors. Advanced engine controllers 
now have some capability to sense, interpret, and act to prevent stalls and 
surging. If this capability is reliable and appropriately activated throughout 
the flight regime, then the Engine Advisor role is one of advising after the fact 
in terms of action alternatives and implications for safety of flight and flight 
replanning. If this automation has not been implemented, then the Engine 
Advisor role is that of alerting the crew in a timely manner of the action 
required. In the first case, improvements focus on increased sensitivity of 
sensors and development of the crew interface capability of Engine Advisor. In 
the second case, improvements focus on adequate sensor development for the 
operational environment and development of the appropriate parameter 
models for an engine model. 
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Information Required for Decision Aiding 
Nature of the Fault : 

In discussing the nature of the fault, we have an interesting problem here. 

The fault, a stability margin problem is not supposed to occur on operational 
engines. Yet operational engines do stall and surge. The question is how well 
does the data we have to develop and test Engine Advisor represent stall and 
surging data from an operational setting? Further, there are a number of 
faults or flight conditions which can produce stall and surging. The problem 
is basically that of detecting the onset of symptoms which lead to stall and 
surging in a timely manner so that either the crew or engine controller can 
take action to prevent the full development of the condition. As outlined above, 
in the first case, the Engine Advisor system must provide an alerting function; 
in the second, an advisory function. 

Relevant Context Variable Set : 

Phase of Flight - Take Off (TOC, TOD ; i.e., significant changes in angle of 
attack ) 8 

Weather - (especially heavy rain) 

FOD Potential - (birds, blown tire parts, etc.) 

Engine Fault History - propensity for stall and surging 
Pilot Error - overreaction in reducing throttle setting(s) 

Workload - high 

Relationship Between Fault and Context Variables for : 

Diagnostic Application - Stall and surging symptoms may be different in either 
degree or sequence or both as a function of phase of flight. The nature of FOD 
source may also affect symptom presence and/or degree. 

Action Alternatives Application - Phase of flight is a key factor in determining 
the appropriateness of action alternatives. Engine fault history may be such 

8 Status information in parentheses indicates status levd of relevant alternative faults. 
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that crews have a good deal of actual experience in dealing with stall and 
surging conditions. 





Stall and surge conditions developing at or near VI can lead to inappropriate 
actions on the part of the pilots. A good deal of accident and incident data 
attest to this. Pilots should take no action at all under these conditions until 
reaching a safe altitude. The need for either timely alerting or appropriate 
advisory information is critical to the selection of the correct action alternative. 
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